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
>
>