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