Hi Leonardo,
To rephrase what I stated before it is the JSF life cycle takes a String
representation to an
Object representation using a Converter to convert THE UI representation
to a Model representation.
It does so during a life cycle phase and I think that contract is clean,
clear and well defined.
And on the way out when rendering the page which is what needed if we
want to represent
it to the customer on a web page a JSF life cycle again uses the
Converter to convert, but now
from a Model representation to THE UI representation.
That summarizes THE sole purpose of the Converter API.
To add a converter chain into the mix here adds unnecessary complexity
and I fail to see how
it is the responsibility of the Converter API. Its responsibility is to
deliver the plumbing to make
Conversion possible. And for that we have defined a set of default
Converters and left
the door open to register more Converters.
This feels a lot like wanting to add additional processing into a spot
where it does not belong.
Regards,
Manfred
On 12/11/14, 12:26 PM, Leonardo Uribe wrote:
> Hi Manfred
>
> 2014-12-11 12:57 GMT-05:00 manfred riem<manfred.riem_at_oracle.com>:
>> 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.
>>
> Agreed.
>
>> 2. Conversion is as defined as taking a String representation to an Object
>> representation and vice versa.
>>
> In the past I have seen the problem is with components that handle Date or
> Time or other complex data types, because this restriction forces to convert
> everything to a String format, instead to define a "natural type" for the
> component. I understand this is done for simplicity, but it is worth to mention
> it, because it changes the way how you should register the converters
> (in an hypothetical solution).
>
>> 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.
>>
> But that's the point. There is not an easy way to fix it. You have to define the
> converter for every component in the view, or rely on hooks that doesn't really
> work the way it supposed to be.
>
> I found this comments done long time ago in
>
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-691
>
> "... Written on behalf of Lincoln Baxter, III:
>
> I propose adding converter chaining, by default, to UIComponent. In effect,
> turning converters into filters.
>
> Sometimes I need to use more than one converter (rich text processing, for
> example) and that leaves me having to write my own converter chain class,
> instantiating that class in a bean, then binding it to my Facelet component
> through EL.
>
> This seems like a lot of work, when what I'd really like to see is converter
> chaining support out of the box. We allow multiple validators, but not multiple
> converters.
>
> Right now, chains only operate on strings, which could cause some confusion,
> potentially, but I see reasons to enable multiple converters per component, and
> convert (in list style) in the order in which the converters were added.
>
> This isn't a hard change, doesn't add much complexity, but does fix one of those
> things that people end up having to do themselves.
>
> Seam has a converter chain, which may serve as a prototype. ..."
>
> Déjà vu?
>
> Leonardo
>
>> 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