Hi Bauke,
Making "true" the default would indeed be the idea.
I think doing that would clarify things.
Anyone else thoughts on this?
Manfred
On 10/16/14, 10:50 AM, Bauke Scholtz wrote:
> Hi,
>
> Without it, the BV's @NotNull wouldn't have any use anymore in JSF and
> models would keep getting polluted with empty strings (which has quite
> different semantics as compared to null), so I don't see why it should
> be phased out.
>
> I'd rather alter JSF impl's own EL resolver to do the desired job
> based on INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL during update
> model values phase.
>
> On the other hand, if we make
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL=true the default
> setting, then we could perhaps indeed phase it out.
>
> Cheers, B
>
>
> On Thu, Oct 16, 2014 at 5:36 PM, manfred riem <manfred.riem_at_oracle.com
> <mailto:manfred.riem_at_oracle.com>> wrote:
>
> Hi Bauke,
>
> Is that the only use case that would still require this setting?
>
> If so could we phase this setting out in 2.3 and tell people that
> would need this to register their own EL resolver and make sure
> that the JSF runtime always uses EL coercion to determine the
> actual value?
>
> What do you think?
>
> Manfred
>
>
> On 10/15/14, 10:37 AM, Bauke Scholtz wrote:
>> Hi,
>>
>> The INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL has still any
>> use. Without it, BV's @NotNull wouldn't have any effect.
>>
>> The problem here is that COERCE_TO_ZERO has in Tomcat been
>> changed to not be applied on java.lang.String anymore. See Tomcat
>> 8 source:
>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-jasper-el/8.0.11/org/apache/el/lang/ELSupport.java#ELSupport.coerceToType%28java.lang.Object%2Cjava.lang.Class%29
>> Compare it to Tomcat 7 source where it get applied on everything,
>> including String:
>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-jasper-el/7.0.55/org/apache/el/parser/AstValue.java#AstValue.setValue%28org.apache.el.lang.EvaluationContext%2Cjava.lang.Object%29
>>
>> This change is indeed a major drawback. I tried to reproduce this
>> on WildFly 8.1.0 which uses com.sun EL impl. It unfortunately
>> also pollutes the model with empty strings during update model
>> values phase after EL-coercing the null submitted value to empty
>> string. I see one possible theoretical trick: fool the EL
>> ValueExpression by telling that we want to resolve it as
>> java.lang.Object instead of java.lang.String.
>>
>> Cheers, Bauke
>>
>>
>>
>> On Wed, Oct 15, 2014 at 5:23 PM, manfred riem
>> <manfred.riem_at_oracle.com <mailto:manfred.riem_at_oracle.com>> wrote:
>>
>> Hi Koen,
>>
>> I think this is a perfect issue to bring up on the new JSF
>> 2.3 Expert Group list, I have copied them.
>>
>> Experts please weigh in and keep Koen on your responses.
>>
>> Note I have removed dev_at_javaserverfaces.java.net
>> <mailto:dev_at_javaserverfaces.java.net> to avoid cross posting.
>>
>> Thanks!
>> Manfred
>>
>> On 10/15/14, 9:08 AM, Koen Serneels wrote:
>>>
>>> Hi,
>>>
>>> When binding a JSF input text to a String property of a JSF
>>> ManagedBean, I want that an empty value is mapped to null
>>> and not "" (empty string).
>>>
>>> So, on tomcat7 (7.0.56) with JSF(2.2 RI) I can get this to
>>> work nicely by controlling the coercing behavior with the
>>> JVM property org.apache.el.parser.COERCE_TO_ZERO icw JSF
>>> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
>>> as context param.
>>>
>>> When
>>> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
>>> is set to true, JSF will set the local component value for
>>> the input component as null when the input if left empty.
>>>
>>> Next, when the value is actually set by tomcat's EL parser,
>>> it will NOT try to coerce the value when
>>> org.apache.el.parser.COERCE_TO_ZERO is set to false and the
>>> value remains null as I want (= OK)
>>>
>>> However (as I first posted this on the tomcat dev
>>> mailinglist) as of Tomcat8 and EL3 , a null value is coerced
>>> to “” (empty String) by the EL parser and the
>>> COERCE_TO_ZERO property has no longer any effect.
>>>
>>> This is as the specification now by default converts “” to
>>> null in case of a non-primitive number. But, in case of
>>> String, the specs says that a empty string (“”) is not
>>> coerced to null and remains empty String.
>>>
>>> The relevant parts from the EL 3 spec:
>>>
>>> 1.23.2 Coerce A to String
>>>
>>> If A is null: return “”
>>>
>>> 1.23.3 Coerce A to Number type N
>>>
>>> If A is null and N is not a primitive type, return null.
>>>
>>> If A is null or "", return 0.
>>>
>>> My questions:
>>>
>>> -Wrt EL3, does the JSF param
>>> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
>>> has any use left?
>>> Since the EL impl converts the null resulting from this
>>> property to empty String according to the spec
>>>
>>> -Is there a way that I can change this behavior in any way
>>> so that I can have null instead of empty String for empty
>>> text fields with Tomcat8/JSF2.2 RI?
>>>
>>> Thanks,
>>>
>>> Koen.
>>>
>>
>