Hi
Looking on the code we have in MyFaces, I see that the renderer calls
Application.createConverter(Class<?> targetClass), but the call is
different according to the component. In components like h:inputText,
the targetClass is derived from the return type of "value" attribute
of the component. In components like h:selectManyMenu and others, the
type cannot be derived, so in tomahawk there is an attribute called
valueType that helps with this. In these cases, the converter is not
attached to the component tree, it is just created "on the fly" and
then discarded. These steps are always done on render response phase.
One possible option is add a method like
Application.createDefaultConverter(UIComponent forComponent), that
takes the component and produce a stateless Converter instance that
will not be bound to the component tree, but that will be used
immediately.
+1 for a default converter.
regards,
Leonardo
2014-12-11 17:04 GMT-05:00 Hanspeter <hampidu_at_gmail.com>:
> Kito,
> yes I bet createConverter() is also called for by-type converters.
>
> I'm not sure if we need that a default-converter-wrapper specified, even
> though there is already a default-validators secion in faces-config.
>
> Implementing that ConverterWrapping on current JSF takes some effort and
> expertise, not only overriding Application.createConverter() but also
> Application.createComponent() to ensure all EditableValueHolder have at
> least that Default-Converter applied.
>
> A specified default-converter-wrapper would probably make it much easier.
>
> +1
> Hanspeter
>
> 2014-12-11 22:48 GMT+01:00 Kito Mann <kito.mann_at_virtua.com>:
>>
>> Hanspeter, doing it in createConverter() isn't a bad idea; it's definitely
>> more performant than walking the component tree. I think
>> Application.createConverter() is still called in the by-type scenario.
>>
>> So rather than worrying about chaining explicitly, what does everyone
>> think about simply having the capability to specify a default Converter in
>> the spec, and passing any other converter (either explicit or by-type) into
>> DefaultConverter's constructor? This is a pretty minor change but allows for
>> chaining or other options if necessary.
>>
>> ___
>>
>> 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
>>
>> On Thu, Dec 11, 2014 at 4:25 PM, Hanspeter <hampidu_at_gmail.com> wrote:
>>>
>>> Hi Kito.
>>> There is a relative simple way to ensure all EditableValueHoolders have a
>>> Converter and also wrap explicitly added converters.
>>>
>>> Wrap Application and override createComponent() and createConverter()
>>> methods.
>>> In createComponent() methods you can check the component type to find out
>>> if you should add your special converter already.
>>> In createConverter() method you can get the wanted converter and wrap it
>>> with your special converter.
>>>
>>> One point to consider is where Converter-for-type is used - I'm not sure
>>> but guess also that should result in callin Application.creatConverter() -
>>> where you can wrap the requested Converter.
>>>
>>> Regards
>>> Hanspeter Duennenberger
>>>
>>> 2014-12-11 16:56 GMT+01:00 Kito Mann <kito.mann_at_virtua.com>:
>>>>
>>>> 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
>>>
>>>
>>
>