Interesting idea. It still doesn't help in my case, where I want one
converter to execute before another, and for them both to take a String as
an input,
On Thu, Dec 11, 2014 at 3:51 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Thu, Dec 11, 2014 at 6:22 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
> > The runtime already has converters available for primitive. Are you
> saying
> > the default converter would be executed before a registered converter?
>
> Yes, that would basically be the idea.
>
> Before I explain further I'd like to mention that I don't really see
> this as a very high priority. As Manfred and Bauke mention, there are
> already various alternatives available.
>
> Anyway, the idea is that JSF now sees the type of a bean's property,
> and in absence of an explicit converter tries to convert to that type
> using a default (registered) converter.
>
> But you could say that if you add an explicit converter, the target
> type that JSF sees now becomes String, and it can pass the request
> value directly (since naturally it already is of type String).
>
> Then if you added an explicit converter that had say Long as input,
> then you could say that the input type JSF sees now becomes Long. JSF
> can then check whether it can provide the input as a Long itself,
> again using a default (registered) converter.
>
> In code:
>
> 1)
>
> #{bean.foo}
>
> public class Bean {
> Long foo; // + getter/setter
> }
>
> ---> JSF looks for converter for String to Long (btw, ignoring EL
> coercion here for a second)
>
>
> 2)
>
> #{bean.foo} converter="someConverter"
>
> public class Bean {
> SomeObject foo; // + getter/setter
> }
>
> @FacesConverter("someConverter")
> public class SomeConverter implements TypedConverter<Long> {
> @Override
> public Object getAsObject(FacesContext context, UIComponent
> component, Long parameter) {
> // ...
> }
> }
>
> ---> JSF looks for converter for String to Long
>
> So in this idea there's conceptually little that changes. There's no
> generic converter chaining, just that the target type JSF sees is
> either that of the bean property, or that of the attached converter in
> case there is one.
>
> Again, not really high priority for me and I haven't really thought
> about any possible consequences of the above approach. Maybe it's a
> silly idea, but since this topic came up now I just wanted to mention
> it here.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
> >
> > ___
> >
> > On Thu, Dec 11, 2014 at 11:26 AM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> For what it's worth, I've had converter chaining on my mind for some
> >> time. One particular use case that I remember this came up is
> >> converting numerical IDs to some entity. This would first need to
> >> convert from String to say Long, and then from Long to say Order.
> >>
> >> Apart from true chaining, a simple 1 step solution might be to have
> >> converters with specific types (possibly via generics), for which the
> >> runtime has global converters available. E.g.
> >>
> >> @FacesConverter("someConverter")
> >> public class SomeConverter implements TypedConverter<Long> {
> >>
> >> @Override
> >> public Object getAsObject(FacesContext context, UIComponent
> >> component, Long parameter) {
> >> // ...
> >> }
> >>
> >> // ...
> >> }
> >>
> >> Kind regards,
> >> Arjan
> >>
> >>
> >>
> >> On Thu, Dec 11, 2014 at 5:04 PM, manfred riem <manfred.riem_at_oracle.com>
> >> wrote:
> >> > Hi Kito,
> >> >
> >> > A phase listener would not do the trick for you?
> >> >
> >> > Note unless I am mistaken what you are describing seems more like a
> >> > corner
> >> > case to me?
> >> >
> >> > Thanks!
> >> > Manfred
> >> >
> >> >
> >> > On 12/11/14, 9:56 AM, Kito Mann wrote:
> >> >
> >> > Hello everyone,
> >> >
> >> > On my current project, I have a situation where I'd like to process
> >> > input
> >> > from _every_ JSF input component on the page. There are a few
> different
> >> > ways
> >> > I can do this, but what I really want is to be able to apply a global
> >> > converter, much like global validators. However, in order to do this,
> we
> >> > would have to have some sort of "converter chaining" mechanism so that
> >> > existing converters won't get clobbered. I could implement this by
> >> > walking
> >> > through all of the EditableValueHolders in the view and adding a
> special
> >> > converter that can wrap an existing converter if necessary. However,
> >> > this is
> >> > something that would work well at the spec level. Thoughts?
> >> > ___
> >> >
> >> > Kito D. Mann | @kito99 | Author, JSF in Action
> >> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> >> > consulting
> >> > http://www.JSFCentral.com | @jsfcentral
> >> > +1 203-998-0403
> >> >
> >> > * Listen to the Enterprise Java Newscast:
> http://enterprisejavanews.com
> >> > * JSFCentral Interviews Podcast:
> >> > http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> >> > * Sign up for the JSFCentral Newsletter:
> >> > http://oi.vresp.com/?fid=ac048d0e17
> >
> >
>