Ah, come on.

You're being polemic, Mike ;)

regards,

Martin

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?

On 8/16/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
On 8/16/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
> > I think the real question is 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 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 should
> consider not everyone is a facelets user.
>
> One user may like using EL or another user may like s:secure. In the end the
> whole idea is to provide out of the box features for security and reduce the
> amount of work and time of myfaces users that they need to enable security.

Yes, but you're adding 2 new files, changing 2 others, writing
documentation and examples, and forcing the rest of us to maintain it.
  :-)

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.

We don't want to be creating a new component every time someone wants
to "save time" by creating a special-case panelGroup :-)

Today <s:secure>, Tomorrow <s:myDataTableHasNoRows>,
<s:myListIsEmpty>, <s:myVariableIsNull>



--

http://www.irian.at

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

Professional Support for Apache MyFaces

Reply via email to