It depends what gets passed as the expected type when
the ValueExpression object is created. If Facelets is passing
java.lang.Object across the boards, and I think it does, you
wouldn't see it. OTOH, if in JSP you specify:
<deferred-value><type>java.lang.String</type></deferred-value>
... for an attribute in JSP 2.1, then you can't get null out
of an EL expression, just the empty string.
-- Adam
On 6/5/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
That's odd. I use the facelets el-ri/el-api.jar files (aren't these
the same thing?) and I haven't had any issues with #{var != null}.
I'd think I'd have at least one null string comparison in the various
projects I've worked on, although I can't be sure.
On 6/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> IIRC, JSF 2.0/JSP 2.1 has the unfortunate behavior of coercing
> null to zero, false, and the empty string, for integers, booleans
> and strings repectively, at least for "get" calls. (The last of those is
> especially annoying.) Don't know about "set" calls offhand.
>
> -- Adam
>
>
>
> On 6/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > fwiw -- hibernate has the same behavior when assigning primitives from
> null values in a resultset.
> >
> > Mike wrote:
> > ========================================
> >
> > Well, I'd say because there's no guarantee that mapping 0 to null is a
> > good choice.
> > It may be that the next user wants null mapped to -1.
> >
> > My suggestion in this described use case is that you use Integer
> > instead of int if there's a possibility that the value could be null.
> > Then you can use whichever value you prefer if you receive a null
> > value. You can make it a wrapper method on another bean if you
> > don;'t want to change the original bean.
> >
> > On 6/5/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > hi,
> > >
> > > following scenario.
> > >
> > > a (form) page renders and it has an input with #{bean.prop}, where
> > > prop is int (not Integer).
> > >
> > > The page renders and the value is 0 (since the variable is declared
> > > like "private int prop;")
> > >
> > > Now I can change it to 3. Fine. When I remove the value (not a
> > > required=true field) I get an
> javax.faces.el.EvaluationException
> > > inside the PropertyResolverImpl.setPropert (...)
> > >
> > >
> > > try
> > > {
> > > m.invoke(base, new Object[] {newValue});
> > > }
> > > catch (Throwable t)
> > > {
> > > log.debug ("Exception while invoking setter method.",t);
> > > throw new
> EvaluationException(getMessage(base, name,
> > > newValue, m), t);
> > > }
> > >
> > >
> > > the getMessage(...) give me this string:
> > > Bean: com.company.Bean, property: prop, newValue: null ,newValue
> > > class: null method parameter class: int
> > >
> > > So far so good, but why not doing a isPrimitive() check on property
> > > and set it to 0 incase of int, for instance.
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > mail: matzew-at-apache-dot-org
> > >
> >
>
>
