Gavin:
>A converter could be useful. But it is mostly useful at the other end,
>when we map the request parameter back to an attribute of a managed
>bean.
I would think the converter would be equally as useful on the other
side as well. If the request param is mapped to an entity then the
converter could convert it to an id when used as a request parameter
and then back to an entity when the redirect-param feature would
normally inject the value back into a managed bean. Just a thought.
Mike
On 7/11/06, jacob_at_hookom.net <jacob_at_hookom.net> wrote:
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=57
>
> :-)
>
> >I've mused on the notion of implementing this via the "PropertyResolver"
> >part of the ELResolver - catch attempts to set properties on beans,
> >and use typing and annotations to convert and validate before
> >pushing through. It could be generically quite powerful, e.g.,
> >provide automatic conversion from IDs to the corresponding entity
> >beans.
> >
> >-- Adam
> >
> >
> >Gavin King wrote:
> >> A converter could be useful. But it is mostly useful at the other end,
> >> when we map the request parameter back to an attribute of a managed
> >> bean. Currently, JSF is a bit lacking in terms of functionality for
> >> handling plain request parameters (as opposed to form values), and this
> >> is something that needs to be fixed in JSF.
> >>
> >> Potentially, plain request parameters could be subject to a similar
> >> "convert"->"validate"->"apply to model" lifecycle that form values go
> >> through.
> >>
> >> -----Original Message-----
> >> From: Stan Silvert
> >> Sent: Tuesday, July 11, 2006 8:24 AM
> >> To: dev_at_javaserverfaces.dev.java.net
> >> Cc: Gavin King; 'jacob_at_hookom.net'
> >> Subject: RE: Re: Redirect Params
> >>
> >>> What do you think of the idea of optionally providing a converter to
> >>> the redirect-param?
> >>
> >> I think it might be a good idea. It might.
> >>
> >> Note once again that the purpose of the redirect param is to support
> >> bookmarking for restful JSF applications.
> >>
> >> However, what actually happens to those params is still an open-ended
> >> question. My original thoughts were that it would be up to the
> >> application developer to figure out how to use the params.
> >>
> >> Jacob, in a thread on another list, suggested that this was unrealistic.
> >> If I understand him correctly, he would say that we need to go ahead and
> >> define the mechanism by which an old view would be resurrected based on
> >> redirect params.
> >>
> >> Attaching a converter would likely be a part of that mechanism.
> >>
> >> Stan Silvert
> >> JBoss, a division of RedHat
> >> ssilvert_at_jboss.com
> >>
> >>> -----Original Message-----
> >>> From: Michael Youngstrom [mailto:youngm_at_gmail.com]
> >>> Sent: Monday, July 10, 2006 11:04 AM
> >>> To: dev_at_javaserverfaces.dev.java.net
> >>> Subject: Re: Redirect Params
> >>>
> >>> Stan,
> >>>
> >>> What do you think of the idea of optionally providing a converter to
> >>> the redirect-param? Something like:
> >>>
> >>> <redirect-param-converter>#{someConverter}</redirect-param-converter>
> >>>
> >>> That would accept either an expression or a converter id.
> >>>
> >>> Mike
> >>>
> >>> On 6/12/06, Stan Silvert <stan.silvert_at_jboss.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Being new to this project, I'm wondering what we do about features
> >>>> that
> >>> go
> >>>> beyond the spec. For instance, I've implemented the ability to add
> >>> params
> >>>> to a redirect:
> >>>>
> >>>>
> >>>>
> >>>> Say I have this in my managed beans declaration:
> >>>>
> >>>>
> >>>>
> >>>> <managed-bean>
> >>>>
> >>>> <managed-bean-name>random</managed-bean-name>
> >>>>
> >>>>
> >>>> <managed-bean-
> >>> class>org.jboss.jsfresearch.boxofchocolates.RandomNumberBean</managed-
> >>> bean-class>
> >>>> <managed-bean-scope>application</managed-bean-scope>
> >>>>
> >>>> </managed-bean>
> >>>>
> >>>>
> >>>>
> >>>> I can now use this in my navigation-case to set a random integer for
> >>> foo:
> >>>>
> >>>>
> >>>> <redirect>
> >>>>
> >>>> <redirect-param>
> >>>>
> >>>> <redirect-param-name>foo</redirect-param-name>
> >>>>
> >>>> <redirect-param-value>#{random.nextInt}</redirect-param-value>
> >>>>
> >>>> </redirect-param>
> >>>>
> >>>> </redirect>
> >>>>
> >>>>
> >>>>
> >>>> When the redirect is executed, the browser will show something like
> >>>> this
> >>>> URL:
> >>>>
> >>>> http://localhost:8080/boxofchocolates/myredirectedpage.faces?foo=123
> >>>> 45
> >>>>
> >>>>
> >>>>
> >>>> This is quite useful for restful applications that support
> >> bookmarking.
> >>> For
> >>>> example, imagine a search form which allows a bookmarkable results
> >>> screen.
> >>>>
> >>>>
> >>>> For redirect params, the code itself is fairly innocuous. The
> >>>> largest change is that the xsd had to be updated beyond the spec.
> >>>> So if you
> >>> like
> >>>> the idea, the question is what to do with my code.
> >>>>
> >>>>
> >>>>
> >>>> Can it be added to the current project?
> >>>>
> >>>> Should we create a sandbox project for features that might make it
> >>>> into JSF.next?
> >>>>
> >>>>
> >>>>
> >>>> Stan Silvert
> >>>>
> >>>> JBoss, a division of RedHat
> >>>>
> >>>> ssilvert_at_jboss.com
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>