You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Eric <ej...@ir.iit.edu> on 2000/11/09 02:01:36 UTC
complex, multidimensional properties
Sorry to post a similar question many times, but I'm striving to get
an answer before the prototype of my project is due.
I'm looking for a way to deal with properties that correspond to form
parameters such as Zoo1Animal1, Zoo1Animal2, Zoo2Animal1, etc. I
would like them represented as two arrays in two seperate beans (a
Zoo array of AnimalForm objects and an Animal array of Strings in the
AnimalForm bean). This seems like something that could be used by a
lot of complex input forms (especially ones that strive to keep inputs
on one page).
My question is, why does BeanUtils.populate not use
PropertyUtils.setProperty? It seems like PropertyUtils.setProperty
would do exactly what I want...is it used anywhere? Is there some tag
that corresponds to it?
Also, is what I'm considering reasonable? Has anyone dealt with
issues like this before? Is it possible for me to modify
BeanUtils.populate so that it uses PropertyUtils.setProperty and thus
provides the functionality I desire? Are there some inherant problems
with this that I'm not seeing?
thanx,
eric.
Re: complex, multidimensional properties
Posted by Eric <ej...@ir.iit.edu>.
I have modified struts to support nested, indexed property names
(i.e. zoos[1].animals[1]) in its forms. Can someone tell me why what
I have done is wrong and why nobody in their right mind would ever do
it? :) I'm not very clear on the distinction between BeanUtils'
property handling methods and PropertyUtils' ones...they seem to
overlap and repeat code (albeit in different ways).
Here is my modified BeanUtils.populate:
public static void populate(Object bean, String prefix, String suffix,
HttpServletRequest request)
throws ServletException {
try {
Enumeration names = request.getParameterNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
String stripped = name;
if (prefix != null) {
if (!stripped.startsWith(prefix))
continue;
stripped = stripped.substring(prefix.length());
}
if (suffix != null) {
if (!stripped.endsWith(suffix))
continue;
stripped =
stripped.substring(0, stripped.length() - suffix.length());
}
// Problems that arise because of
// this switch to setProperty:
// 1. prefix and suffix have little
// meaning for nested properties
// 2. setProperty does no type conversions...although
// it seems like the
// various "convert" methods in BeanUtils could be
// used in it
// this conversion seems to be necessary to support
// both String and String[]
String[] values = request.getParameterValues(name);
if (values != null) {
try {
if (values.length == 1)
PropertyUtils.setProperty(bean, stripped, values[0]);
else
PropertyUtils.setProperty(bean, stripped, values);
} catch (NoSuchMethodException e) {
// ignore form parameters without corresponding properties
}
}
}
} catch (Exception e) {
throw new ServletException("BeanUtils.populate", e);
}
}
Thanks,
Eric
On Wed, Nov 08, 2000 at 05:30:58PM -0800, Craig R. McClanahan wrote:
> Eric wrote:
>
> > Sorry to post a similar question many times, but I'm striving to get
> > an answer before the prototype of my project is due.
> >
>
> Sorry for not being able to give a comprehensive answer earlier ... I've
> had more emergencies this week than I care to think about :-(.
>
> >
> > I'm looking for a way to deal with properties that correspond to form
> > parameters such as Zoo1Animal1, Zoo1Animal2, Zoo2Animal1, etc. I
> > would like them represented as two arrays in two seperate beans (a
> > Zoo array of AnimalForm objects and an Animal array of Strings in the
> > AnimalForm bean). This seems like something that could be used by a
> > lot of complex input forms (especially ones that strive to keep inputs
> > on one page).
> >
>
> I am still not sure that I understand the data model you are trying to
> achieve. Could you sketch out a few simple class and method signatures
> that illustrate the pattern?
>
> >
> > My question is, why does BeanUtils.populate not use
> > PropertyUtils.setProperty? It seems like PropertyUtils.setProperty
> > would do exactly what I want...is it used anywhere? Is there some tag
> > that corresponds to it?
> >
>
> PropertyUtils.setProperty does not do any type conversions -- it assumes
> that your arguments are compatible and will throw exceptions if not.
> BeanUtils.populate knows that the input values are strings, so it looks at
> what the data type of the underlying property is and tries to do the right
> thing. (In the future, it will also respect the existence of
> PropertyEditor classes if you have them for the data types used by your
> beans).
>
> If you want to populate things yourself with PropertyUtils.setProperty,
> this should be possible -- you have access to all of the incoming
> information in the request. But you will need to be responsible for
> converting from Strings (the way you receive all request parameters) to
> the corresponding data types.
>
> >
> > Also, is what I'm considering reasonable? Has anyone dealt with
> > issues like this before? Is it possible for me to modify
> > BeanUtils.populate so that it uses PropertyUtils.setProperty and thus
> > provides the functionality I desire? Are there some inherant problems
> > with this that I'm not seeing?
> >
> > thanx,
> > eric.
>
> Craig McClanahan
>
>
--
_____ _
| ____|(_) http://www.iit.edu/~jenseri
| _| | | Page me via ICQ at
| |___ | | http://wwp.mirabilis.com/19022931
|______/ | or by mailing 19022931@pager.mirabilis.com
|__/
Re[2]: complex, multidimensional properties
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Craig,
I have same problem. Some time ago I try to solve it by rewriting some
portion of code of AcrionServlet. I modify code to support such
properties as myProperty[1], myProperty[2] with indexed
setters, getters:
public void setMyProperty( int index, String value ) {}
public String getMyProperty( int index ) {}
In my database environment I have resultset with records wich contain
some entity info and id for it. Ids in resultset are not
continuous and I need to have 'real' ids of entities in setter to
modify target table in accordance with ids.
I think using of such indexed peoperties as:
public vois getMyProperty( String [] values ) {}
is not good idea in such case because of this method uses transfer of
large amount of data.
But my version of ActionServlet is limited against original version -
it is not support nested proeprties there - only simple and indexed.
Thursday, November 09, 2000, 4:30:58 AM, you wrote:
CRM> Eric wrote:
>> Sorry to post a similar question many times, but I'm striving to get
>> an answer before the prototype of my project is due.
>>
CRM> Sorry for not being able to give a comprehensive answer earlier ... I've
CRM> had more emergencies this week than I care to think about :-(.
>>
>> I'm looking for a way to deal with properties that correspond to form
>> parameters such as Zoo1Animal1, Zoo1Animal2, Zoo2Animal1, etc. I
>> would like them represented as two arrays in two seperate beans (a
>> Zoo array of AnimalForm objects and an Animal array of Strings in the
>> AnimalForm bean). This seems like something that could be used by a
>> lot of complex input forms (especially ones that strive to keep inputs
>> on one page).
>>
CRM> I am still not sure that I understand the data model you are trying to
CRM> achieve. Could you sketch out a few simple class and method signatures
CRM> that illustrate the pattern?
>>
>> My question is, why does BeanUtils.populate not use
>> PropertyUtils.setProperty? It seems like PropertyUtils.setProperty
>> would do exactly what I want...is it used anywhere? Is there some tag
>> that corresponds to it?
>>
CRM> PropertyUtils.setProperty does not do any type conversions -- it assumes
CRM> that your arguments are compatible and will throw exceptions if not.
CRM> BeanUtils.populate knows that the input values are strings, so it looks at
CRM> what the data type of the underlying property is and tries to do the right
CRM> thing. (In the future, it will also respect the existence of
CRM> PropertyEditor classes if you have them for the data types used by your
CRM> beans).
CRM> If you want to populate things yourself with PropertyUtils.setProperty,
CRM> this should be possible -- you have access to all of the incoming
CRM> information in the request. But you will need to be responsible for
CRM> converting from Strings (the way you receive all request parameters) to
CRM> the corresponding data types.
>>
>> Also, is what I'm considering reasonable? Has anyone dealt with
>> issues like this before? Is it possible for me to modify
>> BeanUtils.populate so that it uses PropertyUtils.setProperty and thus
>> provides the functionality I desire? Are there some inherant problems
>> with this that I'm not seeing?
>>
>> thanx,
>> eric.
CRM> Craig McClanahan
--
Best regards,
Oleg mailto:gonza@penza.net
Re: complex, multidimensional properties
Posted by Eric <ej...@ir.iit.edu>.
I have modified struts to support nested, indexed property names
(i.e. zoos[1].animals[1]) in its forms. Can someone tell me why what
I have done is wrong and why nobody in their right mind would ever do
it? :) I'm not very clear on the distinction between BeanUtils'
property handling methods and PropertyUtils' ones...they seem to
overlap and repeat code (albeit in different ways).
Here is my modified BeanUtils.populate:
public static void populate(Object bean, String prefix, String suffix,
HttpServletRequest request)
throws ServletException {
try {
Enumeration names = request.getParameterNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
String stripped = name;
if (prefix != null) {
if (!stripped.startsWith(prefix))
continue;
stripped = stripped.substring(prefix.length());
}
if (suffix != null) {
if (!stripped.endsWith(suffix))
continue;
stripped =
stripped.substring(0, stripped.length() - suffix.length());
}
// Problems that arise because of
// this switch to setProperty:
// 1. prefix and suffix have little
// meaning for nested properties
// 2. setProperty does no type conversions...although
// it seems like the
// various "convert" methods in BeanUtils could be
// used in it
// this conversion seems to be necessary to support
// both String and String[]
String[] values = request.getParameterValues(name);
if (values != null) {
try {
if (values.length == 1)
PropertyUtils.setProperty(bean, stripped, values[0]);
else
PropertyUtils.setProperty(bean, stripped, values);
} catch (NoSuchMethodException e) {
// ignore form parameters without corresponding properties
}
}
}
} catch (Exception e) {
throw new ServletException("BeanUtils.populate", e);
}
}
Thanks,
Eric
On Wed, Nov 08, 2000 at 05:30:58PM -0800, Craig R. McClanahan wrote:
> Eric wrote:
>
> > Sorry to post a similar question many times, but I'm striving to get
> > an answer before the prototype of my project is due.
> >
>
> Sorry for not being able to give a comprehensive answer earlier ... I've
> had more emergencies this week than I care to think about :-(.
>
> >
> > I'm looking for a way to deal with properties that correspond to form
> > parameters such as Zoo1Animal1, Zoo1Animal2, Zoo2Animal1, etc. I
> > would like them represented as two arrays in two seperate beans (a
> > Zoo array of AnimalForm objects and an Animal array of Strings in the
> > AnimalForm bean). This seems like something that could be used by a
> > lot of complex input forms (especially ones that strive to keep inputs
> > on one page).
> >
>
> I am still not sure that I understand the data model you are trying to
> achieve. Could you sketch out a few simple class and method signatures
> that illustrate the pattern?
>
> >
> > My question is, why does BeanUtils.populate not use
> > PropertyUtils.setProperty? It seems like PropertyUtils.setProperty
> > would do exactly what I want...is it used anywhere? Is there some tag
> > that corresponds to it?
> >
>
> PropertyUtils.setProperty does not do any type conversions -- it assumes
> that your arguments are compatible and will throw exceptions if not.
> BeanUtils.populate knows that the input values are strings, so it looks at
> what the data type of the underlying property is and tries to do the right
> thing. (In the future, it will also respect the existence of
> PropertyEditor classes if you have them for the data types used by your
> beans).
>
> If you want to populate things yourself with PropertyUtils.setProperty,
> this should be possible -- you have access to all of the incoming
> information in the request. But you will need to be responsible for
> converting from Strings (the way you receive all request parameters) to
> the corresponding data types.
>
> >
> > Also, is what I'm considering reasonable? Has anyone dealt with
> > issues like this before? Is it possible for me to modify
> > BeanUtils.populate so that it uses PropertyUtils.setProperty and thus
> > provides the functionality I desire? Are there some inherant problems
> > with this that I'm not seeing?
> >
> > thanx,
> > eric.
>
> Craig McClanahan
>
>
--
_____ _
| ____|(_) http://www.iit.edu/~jenseri
| _| | | Page me via ICQ at
| |___ | | http://wwp.mirabilis.com/19022931
|______/ | or by mailing 19022931@pager.mirabilis.com
|__/
Re: complex, multidimensional properties
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Eric wrote:
> Sorry to post a similar question many times, but I'm striving to get
> an answer before the prototype of my project is due.
>
Sorry for not being able to give a comprehensive answer earlier ... I've
had more emergencies this week than I care to think about :-(.
>
> I'm looking for a way to deal with properties that correspond to form
> parameters such as Zoo1Animal1, Zoo1Animal2, Zoo2Animal1, etc. I
> would like them represented as two arrays in two seperate beans (a
> Zoo array of AnimalForm objects and an Animal array of Strings in the
> AnimalForm bean). This seems like something that could be used by a
> lot of complex input forms (especially ones that strive to keep inputs
> on one page).
>
I am still not sure that I understand the data model you are trying to
achieve. Could you sketch out a few simple class and method signatures
that illustrate the pattern?
>
> My question is, why does BeanUtils.populate not use
> PropertyUtils.setProperty? It seems like PropertyUtils.setProperty
> would do exactly what I want...is it used anywhere? Is there some tag
> that corresponds to it?
>
PropertyUtils.setProperty does not do any type conversions -- it assumes
that your arguments are compatible and will throw exceptions if not.
BeanUtils.populate knows that the input values are strings, so it looks at
what the data type of the underlying property is and tries to do the right
thing. (In the future, it will also respect the existence of
PropertyEditor classes if you have them for the data types used by your
beans).
If you want to populate things yourself with PropertyUtils.setProperty,
this should be possible -- you have access to all of the incoming
information in the request. But you will need to be responsible for
converting from Strings (the way you receive all request parameters) to
the corresponding data types.
>
> Also, is what I'm considering reasonable? Has anyone dealt with
> issues like this before? Is it possible for me to modify
> BeanUtils.populate so that it uses PropertyUtils.setProperty and thus
> provides the functionality I desire? Are there some inherant problems
> with this that I'm not seeing?
>
> thanx,
> eric.
Craig McClanahan