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?
regards, Martin On 8/16/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
I'm not doing the work, but if it were me, I'd try to do it as a resolver first due to the increased flexibility to pass method parameters. I wouldn't think it'd be any harder to extend or configure a resolver if it were designed properly. However, it's easier to pass the security bean around, and use it programmically. But either one is acceptable to me. On 8/16/06, Cagatay Civici <[EMAIL PROTECTED]> wrote: > Hi, > > > > There's no new functionality here, and it's not reducing any effort in > > my opinion. This assumes that we go forward and created 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 +1 for the bean, extending and maintaining the bean is also simpler. > > I'm planning to open a jira issue and assign it to myself after we all agree > on the choice. > > Cheers, > > Cagatay > > > On 8/16/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > 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 details of how a resolver is implemented, but > > it seems like it could be configured as easily as anything else. A > > resolver will allow you to get around the method parameter > > limitations. > > > >
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
