On 02/25/10 02:36, Martin Marinschek wrote:
> Hi all once more,
>
> so I just wanted to add my 2cents to the discussion as to what is
> important for starters:
>
> I totally agree that it should be easier to bootstrap the EL - I have
> also had my issues with this before (I e.g. used the EL to write a
> custom excel templating mechanism, and it was pretty hard to get it up
> and run outside of the intended use). So yes please, letīs fix this. I
> will leave the technical discussion on this to the pros.
>
> I would however also love to have two issues fixed which bother me for
> real-life projects. This is:
>
> https://uel.dev.java.net/issues/show_bug.cgi?id=12
>
> which basically means that if a JSF component delivers a null out of
> one of its attributes, the null will always be coerced to an empty
> string or a boolean false or whatever the type of the attribute is. So
> you cannot deliver null values from typed EL expressions.
>
I think we all agree that this needs to be in el.next. I don't think
this needs to much discussion.
> and
>
> https://uel.dev.java.net/issues/show_bug.cgi?id=6
>
> Which means that the parameters that JSF provides to a
> method-expression (e.g. a value-change listener) are lost if there are
> custom parameters provided by the user in the expression. We already
> had a pretty long discussion with Kin-Man on this, and the solution
> might be to provide an implicit parameter in the EL-expression which
> will be replaced with the framework-provided params.
>
Yea, I have a proposal for an EL syntax change for this. I'll put
that out later for discussion.
Thanks
-Kin-man
> best regards,
>
> Martin