The problem with your suggestion of implementing this using the Struts
BeanUtils is that it has been deprecated because its been donated to the
Jakarta Commons project. I understand Struts will be changed to use the
Jakarta Commons version in 1.1. BeanUtils are "utility methods for
populating JavaBeans" and the question is would we be able to persuade
Jakarta Commons to include this when it doesn't have anything to do with
JavaBeans?
If the above were not an issue I would agree with you, changing BeanUtils is
a good solution - it doesn't make mine "wrong" though, just different ;)
Although as you point out I don't "couple Dynamic properties to ActionForms"
it is intended to be used with the "view" and thats why I used Strings in
the getters/setters - this allows errors to be returned to the user with the
data they keyed in. Doing type validation, conversion to various object
types and population of real beans then happens after - and the
implementation of which is a matter of choice. We developed automatic type
validation and conversion mechanisms and a mechanism to automatically
populate DynamicBean(s) (a dynamic equivalent of a JavaBean) from the
GenericActionForm.
For me I would like an interface like the one we developed that we can plug
in - how Struts is changed to implement it I don't mind, as long as we have
the feature.
Presumably we need some committers to agree a solution and someone to do the
work.
Niall
> -----Original Message-----
> From: William Shulman [mailto:[EMAIL PROTECTED]]
> Sent: 30 May 2001 01:53
> To: [EMAIL PROTECTED]
> Subject: RE: PropertyUtils Enhancement Source Code
>
>
>
> I think this *may* solve the problem at the wrong level of
> abstraction. The
> concept of Dynamic Properties, while useful in dealing with forms, has
> nothing to do with forms and ActionForms intrinsicly. Dynamic
> Properties should be available as a tool for any Java programming
> task. I can think of many uses that do not even involve web
> applications. To couple the idea of Dynamic properties to web forms
> would be a mistake.
>
> That said, your solution below does not, per say, couple Dynamic
> properties to ActionForms. It seems that you just want to use Dynamic
> properties with ActionForms, which seems fine to me. Otherwise, you
> suggestion is very similar to the implementation approach I outlined
> below.
>
> Without question, however, Dynamic Properties should be part of the
> struts beans package. Of course I am biased ;), but I think the
> implementation I outlined in my last email on the topic (below) is the
> right way to do this (similar to Niall's approach). There are
> differences, however, with Niall's. For one, getValue and setValue
> should deal with Objects and not Strings. My solution also contains
> the concept of a registry for registering dynamic PropertyMappers
> and how it should be integrated with the PropertyUtils class.
>
> -will
>
> Niall Pemberton writes:
> > I would prefer to see dynamic properties for ActionForms implemented in
> > Struts - which is on the 1.1 ToDo list.
> >
> > We have customized Struts to do dynamic properties along the following
> > lines:
> >
> > 1) Created a "DynamicProperties" interface which has the
> following methods:
> >
> > public String getValue(String property);
> > public String getValue(int index, String property);
> > public void setValue(String property, String value);
> > public void setValue(int index, String property, String value);
> >
> > 2) Sub-classed "ActionServlet" and changed the
> "processPopulate" method to
> > populate the ActionForm using the above setters if its an instance of
> > "DynamicProperties" or using its normal reflection if not.
> >
> > 3) Modified Struts tags to retrieve bean values using the
> above getters if
> > its an instance of "DynamicProperties" or using its normal
> reflection if
> > not.
> >
> > 4) Created a sub-class of ActionForm (DynamicActionForm) which
> implements
> > our "DynamicProperties" interface.
> >
> > Now we only have one DynamicActionForm and don't have to go
> round setting up
> > loads of different "ActionForm" classes. The DynamicActionForm is a bit
> > simplistic and wouldn't suit everyones needs, but the
> advantage of this is
> > people could create their own concrete implementations.
> >
> > It would be interesting to hear others opinions on how dynamic
> properties
> > should be implemented.
> >
> > Niall
> >
> >
> > > -----Original Message-----
> > > From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
> > > Sent: 28 May 2001 16:59
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: PropertyUtils Enhancement Source Code
> > >
> > >
> > > I always like doing things more generic, but in this
> > > particular case I like being able to tell that a value
> > > in a long nested property was a key for a
> > > java.util.Map.
> > >
> > > "foo.someMap.firstPerson.address.zip"
> > > vs.
> > > "foo.someMap{firstPerson}.address.zip"
> > >
> > > It seems like the most common/standard things you
> > > would store something in are arrays, Collection/List,
> > > and a Map. I'm not sure if the indexed property can
> > > handle a Collection or a Collection/List, but it could
> > > easily be modified if it doesn't. The only other
> > > thing left is a Map. So I don't think it is that bad
> > > to have special syntax. There is improved readability
> > > and it would cover the final major interface not cover
> > > by nested properties from the Collections API.
> > >
> > > It would still be nice to have a generic way to plug
> > > in something for other classes though. We'll see what
> > > other people think.
> > >
> > > David
> > >
> > > --- William Shulman <[EMAIL PROTECTED]> wrote:
> > > >
> > > > David-
> > > >
> > > > I think your idea is a great one. Ideally, you would
> > > > configure the
> > > > BeanInfo for Map like classes with a readMethod that
> > > > treats the names
> > > > of Map properties as keys. That way the evalulation
> > > > expression
> > > > "foo.someMap.firstName" would result in 'firstName'
> > > > being treated as a key
> > > > to be looked up in the Map and returned. This is the
> > > > way the java
> > > > beans specification exposes hooks to "override" when
> > > > the '.' operator
> > > > does.
> > > >
> > > > Unfortunately, doing this in practice is quite
> > > > difficult. Without going into
> > > > the details, if you investigate this method in the
> > > > java beans API's you will
> > > > find it quite inflexible. However, the idea is
> > > > right. We should be able to
> > > > explicitly define how properties of a given type are
> > > > accessed and mutated.
> > > >
> > > > I think the right way to implement this is to create
> > > > an interface called
> > > > PropertyMapper and support a mechanism for linking
> > > > property mappers
> > > > with java Classes via a PropertyMapperRegistry.
> > > >
> > > > public interface PropertyMapper {
> > > > public Object getProperty(Object bean, String
> > > > propName);
> > > > public Object setProperty(Object bean, String
> > > > propName, Object propValue);
> > > > }
> > > >
> > > > public class PropertyMapperRegistry {
> > > > public PropertyMapper getPropertyMapper(Class
> > > > type);
> > > > public void registerPropertyMapper(Class type,
> > > > PropertyMapper pm);
> > > > }
> > > >
> > > > Then, the struts PropertyUtils.getPropertyValue and
> > > > setPropertyValue methods
> > > > (I might have the names slightly wrong) would first
> > > > look to see if a
> > > > PropertyMapper is registered for a given type, and
> > > > use that PropertyMapper if
> > > > possible. If a PropertyMapper is not registered for
> > > > a given type, then the
> > > > PropertyUtils falls back to the standard readMethod
> > > > and writeMethod supplied
> > > > by the property's PropertyDescriptor.
> > > >
> > > > Here is how you would implement a PropertyMapper for
> > > > HashMaps
> > > >
> > > > public class HashMapPropertyMapper implements
> > > > PropertyMapper {
> > > > public Object getProperty(Object bean, String
> > > > propName) {
> > > > return( ((HashMap)bean).get(propName) );
> > > > }
> > > >
> > > > public Object setProperty(Object bean, String
> > > > propName, Object propValue) {
> > > > return( ((HashMap)bean).put(propName, propValue)
> > > > );
> > > > }
> > > > }
> > > >
> > > > The reason I favor this approach is:
> > > > (1) This method is very close the initial spirit of
> > > > the Java Beans spec
> > > > (2) No new syntax is introduced. We do not need { }
> > > > and can utilize the
> > > > existing '.' (dot) operator.
> > > > (3) This solution is more general than a solution
> > > > just for HashMaps.
> > > > Although this is applied really well to HashMaps,
> > > > With this method,
> > > > we can implement PropertyMappers for any class. One
> > > > example that comes to
> > > > mind is this (although slightly academic):
> > > >
> > > > Imagine we have a FileManager class that we use to
> > > > create java.io.File
> > > > objects (kind of a File Factory). We might want to
> > > > abstractly define that
> > > > a properties of FileManagers are File objects
> > > > obtained through the
> > > > FileManager, such that we can write expressions like
> > > > this:
> > > >
> > > "someObject.myFileManager./usr/local/apache/logs/error"
> > > >
> > > > To put it simply, we can make the '.' operator mean
> > > > anything we want it to mean
> > > > for a given target class. Kind of cool. This kind of
> > > > thing can also be seen
> > > > in the Python programming language where the
> > > > developer can override the
> > > > imlementation of '.' and is also similar to 'tie' in
> > > > Perl .
> > > >
> > > > -will
> > > >
> > > >
> > > >
> > > >
> > > > David Winterfeldt writes:
> > > > > Here is the source. I've done some basic tests
> > > > and I
> > > > > think everything is working.
> > > > >
> > > > > David
> > > > >
> > > > > --- David Winterfeldt <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > > For an array you can do this for a property
> > > > > > "type[index]". I don't know if this has been
> > > > > > suggested before, but what if you could also do
> > > > this
> > > > > > for a Hashmap. I was thinking something like
> > > > > > form{name}. I'm sure there are lots of other
> > > > uses,
> > > > > > but it could let you make a bean/form class
> > > > that
> > > > > > just
> > > > > > used a Hashmap for rapid prototyping. This
> > > > also
> > > > > > might
> > > > > > be a simple/temporary solution for the beans
> > > > that
> > > > > > don't need setters and getters.
> > > > > >
> > > > > > public Hashmap getForm();
> > > > > >
> > > > > > <html:text property="form{firstName}" size="30"
> > > > > > maxlength="30"/>
> > > > > > <html:text property="form{lastName}" size="30"
> > > > > > maxlength="30"/>
> > > > > > <html:text property="form{address}" size="30"
> > > > > > maxlength="30"/>
> > > > > >
> > > > > >
> > > > > > David
> > > > > >
> > > > > >
> > > > __________________________________________________
> > > > > > Do You Yahoo!?
> > > > > > Yahoo! Auctions - buy the things you want at
> > > > great
> > > > > > prices
> > > > > > http://auctions.yahoo.com/
> > > > >
> > > > >
> > > > >
> > > > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Yahoo! Auctions - buy the things you want at
> > > > great prices
> > > > > http://auctions.yahoo.com/
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Auctions - buy the things you want at great prices
> > > http://auctions.yahoo.com/
> > >
> >
>
