Presumably because the class enhancement knows not to (cannot) enhance a
null!
But there is also the null pattern.
I can supply a reference for this later today if interested.
This is where nulls are handled in the original class on the basis that
really nulls stand in for something else. An example would be where an
integer field is not set when a value is not met. But why can't that integer
field be set to ) or some other default value. IDEs force this on you, at
least for integers, but not for objects. The aim would be to initialize an
object with some useful value, a class that serves this purpose would be in
the class hierarchy.
I think a lot of the frustrating problems with using OGNL (remember you have
to test as well, so the context for tests is different to that of the
rendered page) could be avioded like this. It would also apply to
difficulties in marshelling and unmarshalling the object graph for SOAP
where otherwise nulls make testing very difficult.
What do others think?
Adam

On 28/03/06, Eduardo Valentim <[EMAIL PROTECTED]> wrote:
>
> Hi marc,
>
> You can do this in your page class:
>
>     @Bean
>     public abstract FirstObject getFirstObject();
>
> or, put this in your .page:
>
>     <bean name="firstObject" class="the.package.FirstObject"/>
>
> And in the ognl expression:
>
> ... value="ognl:beans.firstObject.title" ...
>
> AND leaves tapestry to work for you.
>
> I think that I am correct!!! :)
>
> On Tue, 2006-03-28 at 08:27 +0200, Marc Ende wrote:
> > Hi,
> >
> > I'm currently looking for a solution for the following problem:
> >
> > I've got some @Input, @Text and @TextArea Fields in a Form.
> > These are filled with a value="ognl:firstObject.title" for example.
> > If the firstObject is null it causes an exception (source is null for
> > getProperty(null, "title"))
> >
> > I've tried to do something like an @If with condition ognl:firstObject
> > and conditionValue="null" to detect the null and avoid parsing the
> > statements wich causes the exceptions.
> > But this way wasn't successful.
> >
> > So, my question: wich is the common way to handle this cases?
> >
> > Thanks for your help.
> >
> > marc
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to