unsubcribe
Please unsubscribe me ([EMAIL PROTECTED]) from the list
unsubcribe
Please unsubscribe me([EMAIL PROTECTED]) from this list. T,Peri _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: PropertyUtils Enhancement Source Code
I hear what you are saying. You see maps as a first order concept that
you would like formalized in the syntax of bean expressions. I can see
that, but I still do favor staying as close to the original bean
specification as we can without loosing expressiveness. Because using
the '.' operator requires no syntactic changes to the expression
language and can implement the same semantics as 'map{key}', I see no
reason to add new base contructs to the language.
-will
David Winterfeldt writes:
> 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
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 set
