Tomahawk for now, if there's ever something like Faces-Goodies or
Faces-Commons, it should go there.
regards,
Martin
On 8/17/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
where to go?
tomahawk ?
myfaces?
extra lib?
shale ?
On 8/17/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
> I've
where to go?
tomahawk ?
myfaces?
extra lib?
shale ?
On 8/17/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
I've thought more on this and read the entire discussion again. Since
resolver seems more flexible than the bean, I'd say resolver now.
http://issues.apache.org/jira/browse/TOMAHAWK-607
I've thought more on this and read the entire discussion again. Since resolver seems more flexible than the bean, I'd say resolver now.http://issues.apache.org/jira/browse/TOMAHAWK-607
I've assigned it to myself.Cheers,CagatayOn 8/17/06, Martin Marinschek <[EMAIL PROTECTED]
> wrote:Ok, as long as i
Ok, as long as it's compatible with the RI and someone commits the
work, I'm +1 for a custom resolver.
If we want to go for the easier solution of a bean and someone commits
the work for this, I'm +1 for the bean as well.
regards,
Martin
On 8/17/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrot
That resolver sounds interesting, also sorta bean approach is more than nice.
As I read this thread the "new" component is not going to make it. Great.
Adding components like this one looks to me "blow up" the page. Such a
map/resolver looks like a better approach.
Also Mike is right in his Facel
On 8/16/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Hmm, but we suggested to build it as a map-bean to be able to pass
parameters. So what would be the positive aspect of using a resolver
with regard to parameters?
If it's a resolver, you should be able to pass the parameters directly.
Ie
> or a bean. A resolver or a bean makes perfect sense, but a component
> > doesn't.
> >
>
> So we say goodbye to s:secure :)
>
> Ok a bean is a lot more simpler to implement than a resolver for sure, also
> I'd not favor adding a new resolver to the resolver chain.
&g
reated a resolver
> or a bean. A resolver or a bean makes perfect sense, but a component
> doesn't.
>
So we say goodbye to s:secure :)
Ok a bean is a lot more simpler to implement than a resolver for sure, also
I'd not favor adding a new resolver to the resolver chain.
So +
Hi,There's no new functionality here, and it's not reducing any effort inmy opinion. This assumes that we go forward and created a resolver
or a bean. A resolver or a bean makes perfect sense, but a componentdoesn't.So we say goodbye to s:secure :)Ok a bean is a lot more simpl
On 8/16/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
You're being polemic, Mike ;)
You're not the first person who's told me that :-)
P.S.: What do we go for now? A bean or a resolver? What about
extending the thing - it would be easier with a bean, right?
Dunno. Not sure of the detai
eels the need for such a component start using
> > Facelets and implement s:secure as template that generates the
> > panelGroup tag :-)
>
> Typing less and reduced effort is what ROR guys are proud of nowadays:) I
> still think using multiple panel groups looks like a hack and we shoul
eone who strongly feels the need for such a component start using
> Facelets and implement s:secure as template that generates the
> panelGroup tag :-)
Typing less and reduced effort is what ROR guys are proud of nowadays:) I
still think using multiple panel groups looks like a hack and we shou
ement s:secure as template that generates thepanelGroup tag :-)
Typing less and reduced effort is what ROR guys are proud of nowadays:) I still think using multiple panel groups looks like a hack and we should consider not everyone is a facelets user.One user may like using EL or another user may
where to draw the line.Should we
really be maintaining a component that only works for a subset of the
cases and only saves a few characters of typing? I'd recommend that
someone who strongly feels the need for such a component start using
Facelets and implement s:secure as templ
Hi,
@Mario and Martin; nice to see you guys back.
Why don't we create both a security resolver and the secure tag. So the
users may choose the way they want to handle the security.We could also make the s:secure depend on the securityBean so the whole control logic will be done in the bus
a resolver.
regards,
Martin
On 8/16/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
On 8/16/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Well, one reason for having an s:secure tag would be that panelGroup
> will render a span - which we probably don't want in this case.
Hi!
>
>
I know, that this will work, though, it looks like a "hack" (one I often
used ;-) ).
Having a simple secure tag will also reflect what the designer/developer
wanted to do - just secure some components.
Resolving the security through an property resolver or not, having a tag
to clearly
think the
functionality of s:secure is desirable, it's that security checks need
to be handled in EL.
-Mike
Hi Mike,Yes you are right about the limitation of EL.The alternative solutions you provided can definitely solve the security problem but it all depends on the myfaces user to be implemented.My point is to provide some facilities about the security out of the box, so a user can enable security with
On 8/16/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Well, one reason for having an s:secure tag would be that panelGroup
will render a span - which we probably don't want in this case.
Martin, good to see you back :-)
I don't think a panelGroup renders anything unles
Hi,
by the way - if you need to supply more than one parameter, there is
even the possibility to use a double-indexed syntax, as in:
#{securityBean['currentRegion']['manager']}
regards,
Martin
On 8/16/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Well, those are good points, but your conc
Well, those are good points, but your concerns are with the
limitations of the default EL rather than a need for a component.
You can work around these limitations using the
hashmap-as-function-parameters trick, or by using a more advanced EL
(like the Facelets EL which supports user-defined func
this guard component decides whether to render the children components or not. Disabling is also supported.
If we agree on this, I'll commit it to sandbox. Just wanna hear the team's thoughts.CagatayOn 8/16/06, Kumar, Girish <
[EMAIL PROTECTED]> wrote:
Is s:secure already written or
Well, one reason for having an s:secure tag would be that panelGroup
will render a span - which we probably don't want in this case.
I personally tend to think that the map-access like in:
rendered="#{securityBean['myRole'] }"
(yes, you can alternatively write:
render
Is s:secure already written or you want to implement it
?
Can you be more clear on what s:secure does
?
Girish
From: Cagatay Civici
[mailto:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006
10:08 AMTo: MyFaces DevelopmentSubject: Re:
s:secure
Hi Mike,
//components to be
Hi Mike, //components to be secured goes hereYes that would do the same job but my point is the user must create the securityBean class to accomplish this.
Also securityBean changes when a new role is added. Imagining the possible amount of roles, the maintanence of the bean might cause problems
What's wrong with using this?
//components to be secured goes here
Seems a lot more flexible.
On 8/16/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
Hi,
What do you guys think about a security component like this;
//components to be secured goes here
Also have attributes like ifNo
Hi,What do you guys think about a security component like this; //components to be secured goes hereAlso have attributes like ifNotGranted, ifAnyGranted disable and etc.
Do you think this should be useful?Regards,Cagatay
28 matches
Mail list logo
