You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Christopher Yates <CA...@co.stark.oh.us> on 2005/03/14 18:33:25 UTC

Automatic object creation on form submit

Hello,

I'm trying to make CRUD screen as easy as possible.  Right now I am
setting each field to the value of an object in an object graph.  For
example, I have a company class and each field corresponds to objects in
the company class.

The first problem I had with this approach was with OGNL throwing null
pointer exceptions when I would reference objects two or three levels
deep in the graph and it's parent object was null, for example;
company.owner.address.houseNo would throw NullPointerException when
owner is null.  I am using a work-around where I created my own Ognl
NullHandler that returns a new empty object.  Not sure if this is a bad
thing to do for performance reasons, or what not.

Now I'm running into a similar problem but this time for the new/edit
portions where I have a textfield with
value="company.owner.address.houseNo".  If address was null and they are
editing the record, the data they enter for address is lost because it
is actually getting stored in the new object OGNL returned instead of
the actual object in the object graph.

Is there a better approach to all of this?  Keep in mind that I'm
trying to keep the process of developing CRUD screens EASY.  I dont want
to have to put all kinds of extra @Conditionals everywhere and
obj.setAttr(getAttr())'s for each form element.

I think the best solution would be this:

When displaying (when using ognl getAttribute) if any part of the graph
you are referencing is null, return an empty string, since 99% of the
time I would think if you are displaying a field and it's null, then
that's would you would display - nothing.

When submitting a form (when using ognl setAttribute) then if the
object you are referencing is null then set it to a new object and then
set the attribute.  These are all beans with default constructors and
usually only setters/getters...so what's the harm in this?  It would
make things a lot easier, a lot less code.

Any feedback would be greatly appreciated.

-
Chris Yates
Stark County Information Technology
330-451-7432 x4405

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org