myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Expression Language and primitive types
Date Tue, 05 Jun 2007 23:44:05 GMT
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 <mkienenb@gmail.com> 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 <awiner@gmail.com> 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, jacob@hookom.net <jacob@hookom.net> 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 <matzew@apache.org> 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
> > > >
> > >
> >
> >
>

Mime
View raw message