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