Mario,
you're right.
and even if I smell model 1 here, I want this in MyFaces. This is the
KISS principle put into place for JSF.
regards,
Martin
On 4/15/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
> >
> > There is a common tendency for developers using
> > JSF to see any "String in, Object out" case as
> > being Converter-based; I'd recommend against
> > making that assumption. ;)
> >
> >
> > I would agree with that basic sentiment ... after all, the next thing
> > people would want for this use case is validators :-).
> I still dont get you all. Yes the above is true, we want converters and
> validators even for url-get-parameters.
> And I dont know what should be bad with this, It makes absolutely no
> difference if the user entered the stuff in an form or if the data comes
> from the url.
>
> So this is why I propose to use a minimalistic view as (mini)
> controller, though, this is not an requirement, to handle this stuff.
> We can have another tag so we can have the full flexibility as we have
> now in JSF.
>
> In code it might look like this:
>
> <t:getParams>
> <t:getParam id="documentId" value="#{documentBean.documentId}"
> converter="a.b.c.DocumentIdEntityConverter">
> <f:validator .... />
> </t:getParam>
> </t:getParams>
>
> <h:messages/>
>
> the analogy to JSF is, that t:getParams is much like a h:form and
> t.getParam is the same as h:inputHidden.
>
> To get the parameters into the url one can e.g.use outputLink or a
> enhanced navigation rule.
>
> I still cant see what will be bad with this.
>
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
