RE: PropertyUtils & dot notation

[Elli Albek <EA...@altoweb.com>]

We are having exactly the same problem.

Our suggestion was to have some plug in the action Servlet to specify the
classes that will handle the beans mapping, so we can use our own. This can
be done either by sub classing the action Servlet or by having a service
provider API that will allow you to register the implementation in the
Servlet configuration files.

I am not happy to take the code and modify it, this means that every code
change in apache requires manual merge to our code base. Having a hook to
the system can be more robust solution.

E


-----Original Message-----
From: Rey Francois [mailto:Francois.Rey@capco.com]
Sent: Friday, October 19, 2001 12:50 AM
To: 'struts-user@jakarta.apache.org'
Cc: Jakarta Commons Developers
Subject: RE: PropertyUtils & dot notation



The things you're talking about (making the getProperty return null instead
of throwing an error when a nested property is null, and making the
setProperty creating a nested object in the same situation) are indeed not
supported within struts or within the commons BeanUtils. As you said, there
is no hook to extend and do so.

I agree this is definitely a pain to have to deal manually with these
situations. The solution for you would be to either keep using your own
framework for that part, or to modify/extend yourself the commons/struts
BeanUtils, and perhaps submit these enhancements to the list (I think a few
people could benefit from this as well). However you must make sure these
enhancements preserve backward compatibility. This will allow you to have
these enhancements available throughout the whole Struts framework,
including the form tags. This also means you have to work this out behind a
static class that has cached PropertyDescriptors, and static classes are not
that easy to extend! 

Fr.

-----Original Message-----
From: Matt Smith [mailto:msmith@dorado.com]
Sent: 17 October 2001 11:05
To: struts-user@jakarta.apache.org
Subject: PropertyUtils & dot notation


This question has to do with PropertyUtils, so it might be more
appropriately posted to the Commons mailing list, but they don't have a
"User" list so I'm starting here.

My company currently has an page generation framework we developed in-house,
and I'm looking at replacing it with Struts.  I, like some of the users I've
seen on the mailing list, deal with large multi-page forms with many
(sometimes hundreds) of fields, and I really don't want to code setters &
getters for all of them. At first I was particularly worried about the
apparent tight coupling of ActionForms to a particular HTML form, but the
dot-notation of referencing nested bean properties seems to take care of
that nicely. We implemented a very similar system of dot-notation that used
reflection, etc, in the same way, but we made some slightly different
choices and I'm hoping someone can help me with how I could achieve the same
functionality with the struts version.

In PropertyUtils.java, get/setNetstedProperty throw
IllegalArgumentExceptions if any of the getters return null. So if you try
to get a.foo.bar, and getFoo() returns null, then an exception will be
thrown. Likewise, setting a.foo.bar will fail.

The choice we made was that when you're getting, if anything along the path
returned null, then the whole expression was just assumed to be null, and
that was fine. so if getFoo() is null, then getting a.foo.bar is null and
that's kosher. I assume this is solvable with struts, and that somehow I can
ignore the exception. (I just haven't found any hooks into that part of the
framework yet).

The thing I'm more worried about is object creation - we have things set up
so that on sets (and sets only), intermediate objects will be created
automatically. So if you try to set a.foo.bar, and getFoo() is null, then
foo will be created for you so that bar can be set. How is this normally
dealt with in Stuts? Seems like if you have a large object graph that you're
trying to deal with in a general way (letting the HTML people move fields
from page to page, etc), then having to hard-code object creation would be a
huge pain.

Thanks for your time,
-Matt

************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***********************************************************************


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

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>