>>>>> On Thu, 16 Oct 2014 10:36:30 -0500, manfred riem <manfred.riem_at_oracle.com> said:
MR> Hi Bauke,
MR> Is that the only use case that would still require this setting?
MR> If so could we phase this setting out in 2.3 and tell people that
MR> would need this to register their own EL resolver and make sure that
MR> the JSF runtime always uses EL coercion to determine the actual
MR> value?
MR> What do you think?
Considering the amount of trouble that this setting has caused, I oppose
doing anything to change it in a non-backward compatible way.
>>>>> On Thu, 16 Oct 2014 17:50:10 +0200, Bauke Scholtz <balusc_at_gmail.com> said:
B> Without it, the BV's @NotNull wouldn't have any use anymore in JSF and
B> models would keep getting polluted with empty strings (which has quite
B> different semantics as compared to null), so I don't see why it should be
B> phased out.
This dreadful context-param was introduced when we integrated Bean
Validation during JSF 2.0. As Bauke astutely pointed out the BV
@NotNull depends on it.
B> I'd rather alter JSF impl's own EL resolver to do the desired job based on
B> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL during update model values
B> phase.
When you say do the job, do you mean pick up the slack for the EL side
of the problem? If so, I think rather that this is better handled by
the EL spec having a spec defined config setting that we can
programmatically toggle. We may already have this under UEL-38.
B> On the other hand, if we make
B> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL=true
B> the default setting, then we could perhaps indeed phase it out.
-1.
>>>>> On Thu, 16 Oct 2014 10:56:59 -0500, manfred riem <manfred.riem_at_oracle.com> said:
MR> Making "true" the default would indeed be the idea.
MR> I think doing that would clarify things.
MR> Anyone else thoughts on this?
I insist on hearing from those with large amounts of code depending on
the setting before we entertain changing anything here. I'm thinking of
ADF and other products that build on JSF.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 12 work days til Devoxx 2014