You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Marc Ende <ml...@e-beyond.de> on 2006/03/28 08:27:42 UTC
Condition to handle null in forms
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Condition to handle null in forms
Posted by adasal <ad...@gmail.com>.
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 <va...@gmail.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Condition to handle null in forms
Posted by adasal <ad...@gmail.com>.
Mike,
Thanks.
The null object pattern is discussed at some length in various places
including Refactoring in Java
by Joshua Kerievsky, but I just wondered how it played out for others. I
think the idea is never to return a null, but I know I haven't been writing
code like that.
I can see the benefits of dot-pruning, but believe I still have a point. If
I am ever in the same postition again (exstensively using OGNL strings in
hivemind) I will have to revisit this issue. Dot prunning is clearly a
winner for more normal web apps where performance for multiple users is far
more important than ease of development because multiple OGNL dot path
strings have to be easily comprehended and possibly changed. Anyway, that
usually wouldn't be an issue either.
Best,
Adam
On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
>
> Ok. Now I see your point. The problem is that even if you ensure
> that objects are created properly it's hard to ensure that the values
> don't get over-written with nulls -- unless of course you take the
> tack of using a flag value instead of null, using the flag value when
> the user tries to set an object to null. That seems like more of a
> headache then it's worth in most cases, tho.
>
> The benefits of avoiding multiple ognl calls (or dot-pruning as it's
> been called) have been addressed several times in this mailing list
> but (briefly) one poster saw a performance increase of 50% in his
> ognl-heavy app by replacing ognl strings with several dots with calls
> to methods in the container.
>
> If there are alot of methods to write then there are just as many ognl
> calls to write and perhaps duplicate.
>
> I think the performance issue trumps the loss of naming convention.
>
> Thanks,
> -Mike
>
> On 3/28/06, adasal <adam.saltiel@gmail.com > wrote:
> > Not really criticism, just comments/sharing my experience.
> > (Remember that quirk of email that accentuates unment interpretations.)
> > I'm just saying that I understand you to be suggesting additional code
> in
> > the container that will reference the calls you wish to make, then the
> OGNL
> > path is a one step to that class and method. Effectively a wrapper
> around
> > your object model.
> > But if the object model is very complex this means that there is a lot
> of
> > wrapper code to write, albeit very simple in itself. It also seems to me
> > that some of the advantage of having a naming convention maybe lost in
> this
> > way, in particular as with our OM we had nested objects that recur
> > throughout the object graph with getters and setters on their fields, so
> > just by those names you would have no idea where that nested object was.
> > My other point was that it seemed to me that nulls should have been
> dealt
> > with in the parent classes which could always give their own fields some
> > useful values, this would mean you would always be able to instantiate
> > objects safely. This would require some thought. For instance an array
> or
> > hashmap can be instantiated, but what is is supposed o hold. I am
> suggesting
> > there should be a default value for it to meaningfully contain so that
> it
> > can be iterated over safely. In our application an array might contain
> > elements of a form, let's say additional information paragraphs. But if
> the
> > user had no additional information the array would have null elements. I
> am
> > suggesting it should have had one element representing "none". This is a
> bit
> > of a detour to the original question, but related, no? So, I just
> wondered
> > how others deal with this.
> > Adam
> >
> > On 28/03/06, Mike Snare <mikesnare@gmail.com > wrote:
> > >
> > > I'm willing to take criticism, but I must admit that I don't
> > > understand what you're trying to say -- so I can't really respond to
> > > you except to say this:
> > >
> > > Marc wanted a way to handle the case where an object in the ognl chain
> > > was null. 4 different proposals were given. I gave mine as an option
> > > and stated why I preferred it over the other three.
> > >
> > > If you'd like to restate your objection to my suggestion I'm willing
> > > to respond. I'm always interested in learning better ways to do
> > > something, I just didn't understand your response.
> > >
> > > -Mike
> > >
> > > On 3/28/06, adasal <ad...@gmail.com> wrote:
> > > > Mike,
> > > > Not sure howm much your solution is a solution. If you have an
> object
> > > with
> > > > upwards of 3000 nodes and, moreover, the need is to do
> > > > getObjectUsefullName().getPropertyOtherUsefullName() in different
> > > > combinations.
> > > > While OGNL fascilitated this, because usefull names are not lost and
>
> > > also
> > > > those paths can ne encoded in Hivemind rules to e.g. inject values
> into
> > > the
> > > > object being called, a difficulty I encountered was whether the call
> > > should
> > > > be
> > > >
> > >
> getParentOfObjectUsefullName().getObjectUsefullName().getPropertyOtherUsefullName()
> > > > or getObjectUsefullName().getPropertyOtherUsefullName() as only one
> > > would
> > > > ensure the parent was instantiated correctly and non null for the
> > > property
> > > > call. With a large object graph this, of course, bearing in mind
> > > differences
> > > > between testing and production, was a puzzle.
> > > > Adam
> > > >
> > > > On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
> > > > >
> > > > > Another way is to use an accessor method in the container, e.g.
> > > > > getFOTitle(). Implementation as follows:
> > > > >
> > > > > public String getFOTitle() {
> > > > > FirstObject fo = getFirstObject();
> > > > > if (fo != null) {
> > > > > return fo.getTitle();
> > > > > }
> > > > > return "";
> > > > > }
> > > > >
> > > > > It has the benefits of not needing to use the pageBeginRender, not
> > > > > requiring a bean to store it (plus the hit of object creation),
> and
> > > > > reducing the ognl work that needs to be done.
> > > > >
> > > > > Then in your template just use ognl:FOTitle.
> > > > >
> > > > > -Mike
> > > > >
> > > > > On 3/28/06, Eduardo Valentim <va...@gmail.com> 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:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Condition to handle null in forms
Posted by Mike Snare <mi...@gmail.com>.
Ok. Now I see your point. The problem is that even if you ensure
that objects are created properly it's hard to ensure that the values
don't get over-written with nulls -- unless of course you take the
tack of using a flag value instead of null, using the flag value when
the user tries to set an object to null. That seems like more of a
headache then it's worth in most cases, tho.
The benefits of avoiding multiple ognl calls (or dot-pruning as it's
been called) have been addressed several times in this mailing list
but (briefly) one poster saw a performance increase of 50% in his
ognl-heavy app by replacing ognl strings with several dots with calls
to methods in the container.
If there are alot of methods to write then there are just as many ognl
calls to write and perhaps duplicate.
I think the performance issue trumps the loss of naming convention.
Thanks,
-Mike
On 3/28/06, adasal <ad...@gmail.com> wrote:
> Not really criticism, just comments/sharing my experience.
> (Remember that quirk of email that accentuates unment interpretations.)
> I'm just saying that I understand you to be suggesting additional code in
> the container that will reference the calls you wish to make, then the OGNL
> path is a one step to that class and method. Effectively a wrapper around
> your object model.
> But if the object model is very complex this means that there is a lot of
> wrapper code to write, albeit very simple in itself. It also seems to me
> that some of the advantage of having a naming convention maybe lost in this
> way, in particular as with our OM we had nested objects that recur
> throughout the object graph with getters and setters on their fields, so
> just by those names you would have no idea where that nested object was.
> My other point was that it seemed to me that nulls should have been dealt
> with in the parent classes which could always give their own fields some
> useful values, this would mean you would always be able to instantiate
> objects safely. This would require some thought. For instance an array or
> hashmap can be instantiated, but what is is supposed o hold. I am suggesting
> there should be a default value for it to meaningfully contain so that it
> can be iterated over safely. In our application an array might contain
> elements of a form, let's say additional information paragraphs. But if the
> user had no additional information the array would have null elements. I am
> suggesting it should have had one element representing "none". This is a bit
> of a detour to the original question, but related, no? So, I just wondered
> how others deal with this.
> Adam
>
> On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
> >
> > I'm willing to take criticism, but I must admit that I don't
> > understand what you're trying to say -- so I can't really respond to
> > you except to say this:
> >
> > Marc wanted a way to handle the case where an object in the ognl chain
> > was null. 4 different proposals were given. I gave mine as an option
> > and stated why I preferred it over the other three.
> >
> > If you'd like to restate your objection to my suggestion I'm willing
> > to respond. I'm always interested in learning better ways to do
> > something, I just didn't understand your response.
> >
> > -Mike
> >
> > On 3/28/06, adasal <ad...@gmail.com> wrote:
> > > Mike,
> > > Not sure howm much your solution is a solution. If you have an object
> > with
> > > upwards of 3000 nodes and, moreover, the need is to do
> > > getObjectUsefullName().getPropertyOtherUsefullName() in different
> > > combinations.
> > > While OGNL fascilitated this, because usefull names are not lost and
> > also
> > > those paths can ne encoded in Hivemind rules to e.g. inject values into
> > the
> > > object being called, a difficulty I encountered was whether the call
> > should
> > > be
> > >
> > getParentOfObjectUsefullName().getObjectUsefullName().getPropertyOtherUsefullName()
> > > or getObjectUsefullName().getPropertyOtherUsefullName() as only one
> > would
> > > ensure the parent was instantiated correctly and non null for the
> > property
> > > call. With a large object graph this, of course, bearing in mind
> > differences
> > > between testing and production, was a puzzle.
> > > Adam
> > >
> > > On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
> > > >
> > > > Another way is to use an accessor method in the container, e.g.
> > > > getFOTitle(). Implementation as follows:
> > > >
> > > > public String getFOTitle() {
> > > > FirstObject fo = getFirstObject();
> > > > if (fo != null) {
> > > > return fo.getTitle();
> > > > }
> > > > return "";
> > > > }
> > > >
> > > > It has the benefits of not needing to use the pageBeginRender, not
> > > > requiring a bean to store it (plus the hit of object creation), and
> > > > reducing the ognl work that needs to be done.
> > > >
> > > > Then in your template just use ognl:FOTitle.
> > > >
> > > > -Mike
> > > >
> > > > On 3/28/06, Eduardo Valentim <va...@gmail.com> 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:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Condition to handle null in forms
Posted by adasal <ad...@gmail.com>.
Not really criticism, just comments/sharing my experience.
(Remember that quirk of email that accentuates unment interpretations.)
I'm just saying that I understand you to be suggesting additional code in
the container that will reference the calls you wish to make, then the OGNL
path is a one step to that class and method. Effectively a wrapper around
your object model.
But if the object model is very complex this means that there is a lot of
wrapper code to write, albeit very simple in itself. It also seems to me
that some of the advantage of having a naming convention maybe lost in this
way, in particular as with our OM we had nested objects that recur
throughout the object graph with getters and setters on their fields, so
just by those names you would have no idea where that nested object was.
My other point was that it seemed to me that nulls should have been dealt
with in the parent classes which could always give their own fields some
useful values, this would mean you would always be able to instantiate
objects safely. This would require some thought. For instance an array or
hashmap can be instantiated, but what is is supposed o hold. I am suggesting
there should be a default value for it to meaningfully contain so that it
can be iterated over safely. In our application an array might contain
elements of a form, let's say additional information paragraphs. But if the
user had no additional information the array would have null elements. I am
suggesting it should have had one element representing "none". This is a bit
of a detour to the original question, but related, no? So, I just wondered
how others deal with this.
Adam
On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
>
> I'm willing to take criticism, but I must admit that I don't
> understand what you're trying to say -- so I can't really respond to
> you except to say this:
>
> Marc wanted a way to handle the case where an object in the ognl chain
> was null. 4 different proposals were given. I gave mine as an option
> and stated why I preferred it over the other three.
>
> If you'd like to restate your objection to my suggestion I'm willing
> to respond. I'm always interested in learning better ways to do
> something, I just didn't understand your response.
>
> -Mike
>
> On 3/28/06, adasal <ad...@gmail.com> wrote:
> > Mike,
> > Not sure howm much your solution is a solution. If you have an object
> with
> > upwards of 3000 nodes and, moreover, the need is to do
> > getObjectUsefullName().getPropertyOtherUsefullName() in different
> > combinations.
> > While OGNL fascilitated this, because usefull names are not lost and
> also
> > those paths can ne encoded in Hivemind rules to e.g. inject values into
> the
> > object being called, a difficulty I encountered was whether the call
> should
> > be
> >
> getParentOfObjectUsefullName().getObjectUsefullName().getPropertyOtherUsefullName()
> > or getObjectUsefullName().getPropertyOtherUsefullName() as only one
> would
> > ensure the parent was instantiated correctly and non null for the
> property
> > call. With a large object graph this, of course, bearing in mind
> differences
> > between testing and production, was a puzzle.
> > Adam
> >
> > On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
> > >
> > > Another way is to use an accessor method in the container, e.g.
> > > getFOTitle(). Implementation as follows:
> > >
> > > public String getFOTitle() {
> > > FirstObject fo = getFirstObject();
> > > if (fo != null) {
> > > return fo.getTitle();
> > > }
> > > return "";
> > > }
> > >
> > > It has the benefits of not needing to use the pageBeginRender, not
> > > requiring a bean to store it (plus the hit of object creation), and
> > > reducing the ognl work that needs to be done.
> > >
> > > Then in your template just use ognl:FOTitle.
> > >
> > > -Mike
> > >
> > > On 3/28/06, Eduardo Valentim <va...@gmail.com> 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:
> tapestry-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Condition to handle null in forms
Posted by Mike Snare <mi...@gmail.com>.
I'm willing to take criticism, but I must admit that I don't
understand what you're trying to say -- so I can't really respond to
you except to say this:
Marc wanted a way to handle the case where an object in the ognl chain
was null. 4 different proposals were given. I gave mine as an option
and stated why I preferred it over the other three.
If you'd like to restate your objection to my suggestion I'm willing
to respond. I'm always interested in learning better ways to do
something, I just didn't understand your response.
-Mike
On 3/28/06, adasal <ad...@gmail.com> wrote:
> Mike,
> Not sure howm much your solution is a solution. If you have an object with
> upwards of 3000 nodes and, moreover, the need is to do
> getObjectUsefullName().getPropertyOtherUsefullName() in different
> combinations.
> While OGNL fascilitated this, because usefull names are not lost and also
> those paths can ne encoded in Hivemind rules to e.g. inject values into the
> object being called, a difficulty I encountered was whether the call should
> be
> getParentOfObjectUsefullName().getObjectUsefullName().getPropertyOtherUsefullName()
> or getObjectUsefullName().getPropertyOtherUsefullName() as only one would
> ensure the parent was instantiated correctly and non null for the property
> call. With a large object graph this, of course, bearing in mind differences
> between testing and production, was a puzzle.
> Adam
>
> On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
> >
> > Another way is to use an accessor method in the container, e.g.
> > getFOTitle(). Implementation as follows:
> >
> > public String getFOTitle() {
> > FirstObject fo = getFirstObject();
> > if (fo != null) {
> > return fo.getTitle();
> > }
> > return "";
> > }
> >
> > It has the benefits of not needing to use the pageBeginRender, not
> > requiring a bean to store it (plus the hit of object creation), and
> > reducing the ognl work that needs to be done.
> >
> > Then in your template just use ognl:FOTitle.
> >
> > -Mike
> >
> > On 3/28/06, Eduardo Valentim <va...@gmail.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Condition to handle null in forms
Posted by adasal <ad...@gmail.com>.
Mike,
Not sure howm much your solution is a solution. If you have an object with
upwards of 3000 nodes and, moreover, the need is to do
getObjectUsefullName().getPropertyOtherUsefullName() in different
combinations.
While OGNL fascilitated this, because usefull names are not lost and also
those paths can ne encoded in Hivemind rules to e.g. inject values into the
object being called, a difficulty I encountered was whether the call should
be
getParentOfObjectUsefullName().getObjectUsefullName().getPropertyOtherUsefullName()
or getObjectUsefullName().getPropertyOtherUsefullName() as only one would
ensure the parent was instantiated correctly and non null for the property
call. With a large object graph this, of course, bearing in mind differences
between testing and production, was a puzzle.
Adam
On 28/03/06, Mike Snare <mi...@gmail.com> wrote:
>
> Another way is to use an accessor method in the container, e.g.
> getFOTitle(). Implementation as follows:
>
> public String getFOTitle() {
> FirstObject fo = getFirstObject();
> if (fo != null) {
> return fo.getTitle();
> }
> return "";
> }
>
> It has the benefits of not needing to use the pageBeginRender, not
> requiring a bean to store it (plus the hit of object creation), and
> reducing the ognl work that needs to be done.
>
> Then in your template just use ognl:FOTitle.
>
> -Mike
>
> On 3/28/06, Eduardo Valentim <va...@gmail.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Condition to handle null in forms
Posted by Mike Snare <mi...@gmail.com>.
Another way is to use an accessor method in the container, e.g.
getFOTitle(). Implementation as follows:
public String getFOTitle() {
FirstObject fo = getFirstObject();
if (fo != null) {
return fo.getTitle();
}
return "";
}
It has the benefits of not needing to use the pageBeginRender, not
requiring a bean to store it (plus the hit of object creation), and
reducing the ognl work that needs to be done.
Then in your template just use ognl:FOTitle.
-Mike
On 3/28/06, Eduardo Valentim <va...@gmail.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Condition to handle null in forms
Posted by Eduardo Valentim <va...@gmail.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Antwort: Re: Condition to handle null in forms
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
maybe using pageBeginRender for init is a viable solution:
.... extends BasePage implements PageBeginRenderListener{
...
public void pageBeginRender(PageEvent event) {
if(getFirstObject() == null)
setFirstObject(new Object());
}
..
regards,
kris
Sebastiaan van
Erk
<sebster@sebster. An
com> Tapestry users
<ta...@jakarta.apache.org>
28.03.2006 11:04 Kopie
Thema
Bitte antworten Re: Condition to handle null in
an forms
"Tapestry users"
<tapestry-user@ja
karta.apache.org>
That is one way to do it, however make sure you use the right attributes.
<span jwcid="@If" condition="ognl:firstObject">
<!-- your stuff goes here -->
</span>
Regards,
Sebastiaan
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Condition to handle null in forms
Posted by Sebastiaan van Erk <se...@sebster.com>.
That is one way to do it, however make sure you use the right attributes.
<span jwcid="@If" condition="ognl:firstObject">
<!-- your stuff goes here -->
</span>
Regards,
Sebastiaan
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org