On Wed, 30 May 2001, William Shulman wrote:
>
> > 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 Comm
> > 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 metho
> 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
>
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
>
ly want to see what Struts does because if it suits us,
better to use the vanilla Struts solution.
Niall
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]]
> Sent: 30 May 2001 10:07
> To: [EMAIL PROTECTED]
> Subject: RE: PropertyUtils Enhancement Source
7;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
> >
> >
>
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
&
> 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
vantage 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 Winter
interfeldt [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 nest
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 req
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 y
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
13 matches
Mail list logo
