some quick notes.
can you file a jira ticket?
the el is now more type safe, less lenient (in JSF 12/unifed el)
(in a rush)
-M
On Fri, Dec 5, 2008 at 12:28 PM, Martin Kočí <[EMAIL PROTECTED]> wrote:
>
> Matthias Wessendorf píše v Čt 04. 12. 2008 v 16:17 +0100:
>> 2008/12/4 Matthias Wessendorf <[EMAIL PROTECTED]>:
>> > Are you using Trinidad 1.0.x ?
>> > Or 1.2.x
>>
>> ok, this fix is only on 1.2.x
>> so you are using that-
>>
>> -M
>>
>> >
>> > I added a call to the converter to convert index type of Integer to
>> > the model type so that it doesn't get a validation error when
>> > valuePassThru is false. This was caused by the change in EL
>> > processing (this change is only true on JSF 1.2 / Unified EL)
>
> I don't think that is the right solution. We must think about
> valuePassThru feature as a special JSF converter. The problem we are
> solving is conversion Server Side Object <-> HTML String Representation
> of Object.
>
> Case 1: valuePassThru=false (default in trinidad). There is a business
> object (in most cases a persistent entity) as SelectItem.value. Renderer
> encodes that values as index in collection. So this behaviour is similar
> to converter.getAsString method, but is performed with renderer and
> registered converter is skipped.
>
> Fo decoding renderer takes the String from HTML, makes a Integer from it
> (the index) and finds corresponding SelectItem. The it takes
> SelectItem.value as "converteted" value. Very similar to
> converter.getAsObject, but converter is skipped again.
>
> Case 2: valuePassThru=true. This is "standard" behaviour from JSF RI
> (h:selectOneABC). For encoding there is used converer.getAsString method
> which produces String HTML represenation of SelectItem.value.
>
> For decoding converer.getAsObject is used. I takes the string
> represenation and "finds" corresponding server side object. It can be a
> JPA Entity instance or simple Integer.parseInt(string).
>
>
>
>
> But actual 1.2.10 does following: it performs decoding as described in
> case 1 (result of that is a instance from sellectIytem.value) then it
> converts the instance to String again (with .toString() method) and then
> converter.getAsString is applied (as in case 2 decoding). I think this
> is a impropriate mixture of two approaches.
>
>
> What is the problem with Unified EL? I know there is some special
> "feature" of converting "" (empty String) to zero instead of null. Is
> this the case?
>
>
> Martin
>
>
>
>> >
>> > On Thu, Dec 4, 2008 at 4:07 PM, Martin Kočí <[EMAIL PROTECTED]> wrote:
>> >> Yes,
>> >>
>> >> but can you explain what TRINIDAD 1225 really does/wants? I want provide
>> >> a patch including that functionality.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Matthias Wessendorf píše v Čt 04. 12. 2008 v 15:33 +0100:
>> >>> can you open a jira ticket ?
>> >>>
>> >>> On Thu, Dec 4, 2008 at 2:55 PM, Martin Kočí <[EMAIL PROTECTED]> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > TRINIDAD 1225 changed method
>> >>> > SimpleSelectOneRenderer._convertIndexedSubmittedValue(FacesContext,
>> >>> > UIComponent, Object)
>> >>> >
>> >>> >
>> >>> > from
>> >>> >
>> >>> > SelectItem item = selectItems.get(index);
>> >>> > if (item != null)
>> >>> > return item.getValue();
>> >>> > else
>> >>> > return null;
>> >>> >
>> >>> >
>> >>> > to
>> >>> >
>> >>> > SelectItem item = selectItems.get(index);
>> >>> > if (item != null)
>> >>> > {
>> >>> > Object converted = item.getValue();
>> >>> > if (converter != null && converted != null)
>> >>> > {
>> >>> > converted = converter.getAsObject(context, component,
>> >>> > converted.toString());
>> >>> > }
>> >>> > return converted;
>> >>> > }
>> >>> > else
>> >>> > {
>> >>> > return null;
>> >>> > }
>> >>> >
>> >>> > Problem: each one SelectItem instance has an entity object as value
>> >>> > (for example an instance User) and valuePassThru=false -> renderer
>> >>> > encodes select item values as indexes in HTML. Before TRINIDAD 1225
>> >>> > simple item.getValue() was uses in decode, but now
>> >>> > converter.getAsObject is called.
>> >>> >
>> >>> > I think the convenience of valuePassThru feature is the no need for
>> >>> > getAsObject implementation in converters. But now this is gone.
>> >>> >
>> >>> >
>> >>> > Regards,
>> >>> >
>> >>> > Martin
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>>
>>
>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf