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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> 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
