You have a point about the purpose of a converter, Manfred. Perhaps I'm
thinking more of an "input filter". Basically I'm looking for a global way
to handle any input.
On Thu, Dec 11, 2014 at 12:57 PM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> Hi Leonardo and the rest,
>
> While I am not opposed to exploring any proposals I want to put out there
> that everything that comes to the table needs to be looked from the larger
> perspective.
>
> For conversion this comes to mind:
>
> 1. Conversion is done in a particular phase and we have a well established
> pattern for doing so, changing anything here will need a very high
> level of
> scrutiny because it is fundamental to the JSF life cycle.
>
> 2. Conversion is as defined as taking a String representation to an Object
> representation and vice versa.
>
> 3. Conversion is currently tied to components as per the defined API.
>
> If you want more dynamic behavior for conversion for most components
> you can define the convertor to be used, or as Bauke and I already
> suggested
> there are other hook in points.
>
> Manfred
>
>
> On 12/11/14, 11:41 AM, Leonardo Uribe wrote:
>
>> Hi
>>
>> MR>> A phase listener would not do the trick for you?
>>
>> Not every instance of EditableValueHolder is a visual input field. For
>> example h:inputHidden or f:viewParam. A cast for UIInput will not work
>> (both f:viewParam and h:inputHidden extends from UIInput).
>>
>> BS>> A component system event listener for post validate event
>> targeted at UIInput should do it.
>>
>> I understand it could work in some cases but the idea is the converter
>> executed before any validation.
>>
>>
>> This is an spec issue. The problem is the approach we have to handle
>> converters is too fixed. At build time, you define an association
>> between a component and a converter.
>>
>> That's ok, but what happen if you don't want that? what if your
>> component receive an object and the converter should be resolved at
>> runtime, or based on the value binding the conversion is performed?
>>
>> What you have in the spec is a per type conversion, but that's too
>> rigid. What if the component uses an internal diferent of String
>> (java.util.Date or other) and what you require is a different
>> converter? Or if you have an "upper case converter" or a converter of
>> a type that do something special?
>>
>> The problem is there is no way to define a "conversion strategy" for
>> components. For example, there is a component x that uses String as
>> internal representation and can handle Long, Integer and MyEntity
>> types through some specified converters. The big problem with the idea
>> is you need a bidirectional conversion, and there are cases where you
>> just don't know the target type.
>>
>> This can't be done properly without an spec change, because you
>> require a central place to register the converters and the "conversion
>> strategies".
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2014-12-11 11:32 GMT-05:00 manfred riem<manfred.riem_at_oracle.com>:
>>
>>> Hi Bauke,
>>>
>>> Excellent other choice ;)
>>>
>>> Manfred
>>>
>>>
>>> On 12/11/14, 10:19 AM, Bauke Scholtz wrote:
>>>
>>> Hi,
>>>
>>> A component system event listener for post validate event targeted at
>>> UIInput should do it.
>>>
>>> Cheers, B
>>>
>>> On Dec 11, 2014 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
>>>>
>>>