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 <[EMAIL PROTECTED]> 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 <[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]
>
>
