From adffaces-user-return-640-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org Tue Aug 08 20:26:53 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-user-archive@locus.apache.org Received: (qmail 18256 invoked from network); 8 Aug 2006 20:26:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Aug 2006 20:26:53 -0000 Received: (qmail 62277 invoked by uid 500); 8 Aug 2006 20:26:52 -0000 Delivered-To: apmail-incubator-adffaces-user-archive@incubator.apache.org Received: (qmail 62262 invoked by uid 500); 8 Aug 2006 20:26:52 -0000 Mailing-List: contact adffaces-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-user@incubator.apache.org Delivered-To: mailing list adffaces-user@incubator.apache.org Received: (qmail 62253 invoked by uid 99); 8 Aug 2006 20:26:52 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Aug 2006 13:26:52 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of awiner@gmail.com designates 66.249.92.170 as permitted sender) Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Aug 2006 13:26:51 -0700 Received: by ug-out-1314.google.com with SMTP id u40so2755ugc for ; Tue, 08 Aug 2006 13:26:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M/TgwbMS/wnla4a7E6u6JDWz0528M80GtyW3ND/R0Eo+eMq9Z3KP3TtSJZLX1LYQMx58DGmJuKz4yfNRFzp+etZwJbrVb/GGlEWimYbEorhKqV8JdBpLt0wiZyi85bxqjt8uZg13fl9+02GkwgK303m2/FbagquUWjV2zk8XYvE= Received: by 10.66.216.6 with SMTP id o6mr30989ugg; Tue, 08 Aug 2006 13:26:29 -0700 (PDT) Received: by 10.67.102.15 with HTTP; Tue, 8 Aug 2006 13:26:29 -0700 (PDT) Message-ID: <6dac79b90608081326nf1fe67ev6b74f3841a233224@mail.gmail.com> Date: Tue, 8 Aug 2006 13:26:29 -0700 From: "Adam Winer" To: adffaces-user@incubator.apache.org Subject: Re: Re: Trinidad and Tomahawk In-Reply-To: <44D8C63E.5090601@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <35A72025A61EE3488E4CF824C717F70E038579C4@OAEXCH1SERVER.oa.oclc.org> <6dac79b90608070840h1922a3a5o95355cf49bfed2b8@mail.gmail.com> <44D8C63E.5090601@oracle.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Frank, I think the best way to implement this is to have a Map that handles this transformation for you, so you can say: disabled="#{userInRole['manager']}" This sort of bean should be exposed out-of-the-box (would be nice if it in were in the JSF standard, but easy enough to write on your own). Some problems with creating bonus properties are that you: (A) Have to remember to add them to all components (B) Have to expose multiple properties, one for everything that might be affected - rendered, readonly, disabled. (C) Aren't helped if you need to bind some other attribute (what if you wanted a different styleClass depending on the role?) (D) Aren't helped if you're not using only the absolute standard user-in-role mechanism - no, one size *does not* fit all (E) Impose performance overhead on *all* components, even those that don't need the attribute, since you have to get the property and check it no matter what These are, more-or-less, the same reasons why I argued fiercely against adding "bundle" properties for translation and in favor of using EL for that purpose - a decision I'm convinced has been proven correct. -- Adam On 8/8/06, Frank Nimphius wrote: > Adam, > > EL doesn't allow arguments in which case isUserInRole() checking > requires the developer to create a managed bean first to then provide > boolean return values. Though not reflected in the JSF spec, I think > that providing out-of-the box security always is a benefit. At least > this way you can ensure it is implemented the est way possible. However, > this goes beyond implementing security on a single UI Component only but > requires security to be enabled on the JSF engine. > > Just my 2 cents on it > > Frank > > Adam Winer wrote: > > There has not been a decision on adding either role checking > > or force ID to Trinidad. > > > > My personal starting position is that I'd be -1 on adding > > either. Role checking is better accomplished via setting > > EL on disabled and readOnly, and force ID is unnecessary > > in JSF 1.2 with h:form prependId="false" (and the > > removal of requirements for using f:subview). > > > > -- Adam > > > > > > On 8/7/06, Baker,Jonathan wrote: > >> > >> I believe that I read somewhere that while in incubation the important > >> attributes of tomahawk (forceid, role checking) would be added to the > >> trinidad components. Unfortunately I cannot remember or find where I > >> read that statement. I wanted to verify with the list that this is > >> true. Will trinidad and tomahawk eventually be merged into one set of > >> components that support the skinning and things of ADF, but also support > >> the forceid, and role checking of tomahawk. > >> > >> JB > >> > >> > >> > > > > -- > > ________________________________ > Frank Nimphius > Principal Product Manager > Application Development Tools > Oracle Corporation > mail: frank.nimphius@oracle.com > phone:+49 2058 782481 > >