incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: Re: Trinidad and Tomahawk
Date Wed, 16 Aug 2006 09:31:37 GMT
Adam's workaround for using map-parameters as function parameters is
implemented in two MyFaces-helper classes  - named ActionMap and
TestsMap.

regards,

Martin

On 8/8/06, Adam Winer <awiner@gmail.com> wrote:
> Frank,
>
> I think the best way to implement this is to have a Map<String, Boolean>
> 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 <frank.nimphius@oracle.com> 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 <BakerJ@oclc.org> 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
> >
> >
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Mime
View raw message