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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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]
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
