MR> This feels a lot like wanting to add additional processing into a spot
where it does not belong.
+1
Only improvement for current Converter (and Validator) interface I'd like
to see is to generify Object by T. This should be possible without breaking
existing converters.
Cheers, B
On Thu, Dec 11, 2014 at 7:58 PM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> 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
>>>>>>
>>>>>