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
>
>