You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Roland Huss <Ro...@consol.de> on 2001/05/22 22:49:02 UTC
Extensions to Struts
Ahoi,
first all thanx for this real fantastic framework, excellent work!.
We here at ConSol are developing a web frontend for our helpdesk
software based on struts and for the time being we have about 30
actions, 35 custom tags, 110 JSP-Pages (without any explicite java
code!) and appr. 20k lines of Java code and it turned out that struts
was a great support from the very beginning.
In course of the development during the last three month, we made some
extensions, which we would happily contribute to struts.
Our extensions are listed below briefly. If there's some interest
in some of them, please leave a note (note that I will be absent till
wednesday in a week, so don't expect a response before)
* Followups. Followups are a simple mechanism for an action to return
to the place before it was called. Therefore we implemented a
FollowupStack which is passed around in URLs and Forms (as hidden
parameters). An action only needs simply to call "getFollowup()" in its
perform() method to get a forward to the previous action. (Therefore
FormTag and Action was extended).
* Action documentation. For documentation of actions, we introduced
three new javadoc tags: @input (input parameters expected by this
action in its request) , @output (results put into request scope)
and @forward (possible forwards of this action). To support these
new tags we've written two javadoc Doclets: The first is extending
the standard doclet for rendering an HTML table in the class
documentation in javadoc. The other one creates XML-output, which we
use with an XSL stylesheet to convert it to the stylebook DTD for
the online documentation.
* Hidden Parameters. Our extension of Action has an
"addHiddenParameter()" method which put hidden parameters into
request scope which our subclassed FormTag renders as
HTML-Tags. With this method it is very easy to push parameters around
to several actions (without polluting session scope).
* Image Buttons. This an extension to SubmitTag for rendering image
buttons and handling enabled/disabled buttons based on the existance
of some object stored in request scope. Our actions can check for the
trigger of a submit button regardless whether it was submitted as a
submit button or an image-map.
* Extra parameters in URLs. Our extended "Action" gives subclasses a
change to append extra parameters to a forward by overriding a
"getExtraParameters()" which will be appended to a forward.
* From action to JSP. Not really an extension, but it proved for us to be
very useful to stick to the simple paradigm, that a page is only
accessed via an action and any JSP-Page is only referenced via an
action. JSP pages are really only used for rendering the result
calculated by the previous action, which passes them to the JSP page
by putting them into request scope. Though it might look rather
restrictive, this design descision proved to be very useful mainly
due to its simplicity.
Well, thats all I remember for the moment. We developed some custom
tags, which might prove to be useful on its own (and not only for our
application), but that's another story.
cu....
--
...roland huss
consol.de
Re: Extensions to Struts
Posted by stefan werner <st...@netcologne.de>.
hi,
this sounds very interesting to me.
So, if you don't mind, i'd like to take a look.....
regards
stefan werner
----- Original Message -----
From: "Roland Huss" <Ro...@consol.de>
To: <st...@jakarta.apache.org>
Sent: Tuesday, May 22, 2001 10:49 PM
Subject: Extensions to Struts
> Ahoi,
>
> first all thanx for this real fantastic framework, excellent work!.
> We here at ConSol are developing a web frontend for our helpdesk
> software based on struts and for the time being we have about 30
> actions, 35 custom tags, 110 JSP-Pages (without any explicite java
> code!) and appr. 20k lines of Java code and it turned out that struts
> was a great support from the very beginning.
>
> In course of the development during the last three month, we made some
> extensions, which we would happily contribute to struts.
>
> Our extensions are listed below briefly. If there's some interest
> in some of them, please leave a note (note that I will be absent till
> wednesday in a week, so don't expect a response before)
>
> * Followups. Followups are a simple mechanism for an action to return
> to the place before it was called. Therefore we implemented a
> FollowupStack which is passed around in URLs and Forms (as hidden
> parameters). An action only needs simply to call "getFollowup()" in its
> perform() method to get a forward to the previous action. (Therefore
> FormTag and Action was extended).
>
> * Action documentation. For documentation of actions, we introduced
> three new javadoc tags: @input (input parameters expected by this
> action in its request) , @output (results put into request scope)
> and @forward (possible forwards of this action). To support these
> new tags we've written two javadoc Doclets: The first is extending
> the standard doclet for rendering an HTML table in the class
> documentation in javadoc. The other one creates XML-output, which we
> use with an XSL stylesheet to convert it to the stylebook DTD for
> the online documentation.
>
> * Hidden Parameters. Our extension of Action has an
> "addHiddenParameter()" method which put hidden parameters into
> request scope which our subclassed FormTag renders as
> HTML-Tags. With this method it is very easy to push parameters around
> to several actions (without polluting session scope).
>
> * Image Buttons. This an extension to SubmitTag for rendering image
> buttons and handling enabled/disabled buttons based on the existance
> of some object stored in request scope. Our actions can check for the
> trigger of a submit button regardless whether it was submitted as a
> submit button or an image-map.
>
> * Extra parameters in URLs. Our extended "Action" gives subclasses a
> change to append extra parameters to a forward by overriding a
> "getExtraParameters()" which will be appended to a forward.
>
> * From action to JSP. Not really an extension, but it proved for us to be
> very useful to stick to the simple paradigm, that a page is only
> accessed via an action and any JSP-Page is only referenced via an
> action. JSP pages are really only used for rendering the result
> calculated by the previous action, which passes them to the JSP page
> by putting them into request scope. Though it might look rather
> restrictive, this design descision proved to be very useful mainly
> due to its simplicity.
>
> Well, thats all I remember for the moment. We developed some custom
> tags, which might prove to be useful on its own (and not only for our
> application), but that's another story.
>
> cu....
> --
> ...roland huss
> consol.de
>
Re: Extensions to Struts
Posted by Roland Huss <Ro...@consol.de>.
Ted Husted <hu...@apache.org> writes:
> If you like, I would be happy to offer them at
>
> < http://www.husted.com/about/struts/ >
>
> or a link to a place where they can download them from you site.
>
> Very soon, I hope to begin work on a place where you will be able to
> upload these types of extensions and custom tags directly, so it will be
> easier for Struts users to share new ideas, and help streamline the
> contribution process.
Many thanks for the responses. At the moment I'm packaging up and
extracting the extension as described in my last mail. As soon as I'm
finished, I will send them to Ted for provision on his site.
I still think about an appropriate Java namespace for the packages
(see my next mail) and I'm going to construct a complete build
environment, so it may take another week, before the extensions are
available. Please stand by.
cu....
--
...roland huss
consol.de
Re: PropertyUtils Enhancement Source Code
Posted by William Shulman <wi...@metaconsortium.com>.
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 <wi...@metaconsortium.com> 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 <dw...@yahoo.com>
> > 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/
RE: PropertyUtils Enhancement Source Code
Posted by Niall Pemberton <ni...@btInternet.com>.
> > 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?
>
> This should not be that big of an issue. AND, DynamicPropertyMappers
> (or whatever we want to call them) has everything to do with JavaBeans in
> my opinion.
>
> -will
>
OK so get on bugzilla and submit your proposal as an enhancement to Jakarta
Commons. AND, I don't see this in the JavaBeans spec (nice as it would be).
http://java.sun.com/products/javabeans/docs/spec.html
Niall
RE: PropertyUtils Enhancement Source Code
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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 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?
>
> This should not be that big of an issue. AND, DynamicPropertyMappers
> (or whatever we want to call them) has everything to do with JavaBeans in
> my opinion.
>
The reason that BeanUtils and friends are in commons is because they were
already much better than alternative attempts at this approach. Don't
worry about commons accepting dynamic properties -- that will just make
these routines 'more better'.
> -will
>
Craig
RE: PropertyUtils Enhancement Source Code
Posted by William Shulman <wi...@metaconsortium.com>.
> 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?
This should not be that big of an issue. AND, DynamicPropertyMappers
(or whatever we want to call them) has everything to do with JavaBeans in
my opinion.
-will
RE: PropertyUtils Enhancement Source Code
Posted by Johan Compagner <jc...@j-com.nl>.
You got my Vote (see my other mail)
Johan Compagner
> 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:dwinterfeldt@yahoo.com]
> > > Sent: 28 May 2001 16:59
> > > To: struts-dev@jakarta.apache.org
> > > 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 <wi...@metaconsortium.com> 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 <dw...@yahoo.com>
> > > > 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/
> > >
> >
RE: PropertyUtils Enhancement Source Code
Posted by Niall Pemberton <ni...@btInternet.com>.
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:will@metaconsortium.com]
> Sent: 30 May 2001 01:53
> To: struts-dev@jakarta.apache.org
> 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:dwinterfeldt@yahoo.com]
> > > Sent: 28 May 2001 16:59
> > > To: struts-dev@jakarta.apache.org
> > > 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 <wi...@metaconsortium.com> 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 <dw...@yahoo.com>
> > > > 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/
> > >
> >
>
RE: PropertyUtils Enhancement Source Code
Posted by William Shulman <wi...@metaconsortium.com>.
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:dwinterfeldt@yahoo.com]
> > Sent: 28 May 2001 16:59
> > To: struts-dev@jakarta.apache.org
> > 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 <wi...@metaconsortium.com> 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 <dw...@yahoo.com>
> > > 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/
> >
>
RE: PropertyUtils Enhancement Source Code
Posted by Niall Pemberton <ni...@btInternet.com>.
Johan
I take that as definite No! with no room for negotiation - oh shit, better
tell my boss I did it all wrong ;)
As I said to William...
The problem of implementing this using the Struts BeanUtils is that it has
been deprecated because its been donated to the Jakarta Commons project -
will we be able to persuade Jakarta Commons to include this when it doesn't
have anything to do with JavaBeans?
My interface is more minimalistic than yours because its tightly focused on
all Struts needs to do i.e. get and set values. How people implement it is
up to them - how properties a stored (doesn't have to be a HashMap), getting
a list of properties (i.e your getBeanProperties() method) and type
conversion can all be implemented in your own flavour of ActionForm (which
is what we did).
Thanks for your offer of code - these aspects of our system are done and
working and I really 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:jcompagner@j-com.nl]
> Sent: 30 May 2001 10:07
> To: struts-dev@jakarta.apache.org
> Subject: RE: PropertyUtils Enhancement Source Code
>
>
> > 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);
>
> Almost the samething i have now. I only have some more (and i
> don't have at
> this time the index because
> i don't believe that is nessesary, because BeanUtils / PropertyUtils are
> taking care of that!
>
> This is My interface that i use for quite sometime know.
>
> public interface Property
> {
> public java.util.Map getBeanProperties(); // Is
> needed for the new describe
> method in PropertyUtils!!
> public Object getBeanProperty(String sPropertyName);
> public Class[] getParameterTypes(String sName); // You should be
> able to get
> the types of the property.
> public void setBeanProperty(String sPropertyName, Object oPropertyValue);
> }
>
>
> > 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.
>
> No!
> ActionServlet doesn't have to change at all!!
> Everychange must only be done in the PropertyUtils and BeanUtils.
> What does ActionServlet to do with beans? Nothing. Struts only
> uses the Bean
> And property utils
> for filling the beans. At this time only with reflection but i
> changed Bean
> And PropertyUtils
> so that it looks for the above Interface Property and then calls
> the get or
> set of that Property Interface.
>
> Here some code i changed in the PropertyUtils class:
>
> public static void setSimpleProperty(Object bean, String name,
> Object value)
> {
> // If it is of Property
> if (bean instanceof Property)
> {
> // Use that one instead of Reflection (you create
> youre own reflection
> interface)
> ((Property) bean).setBeanProperty(name, value);
> }
> else
> {
> // Retrieve the property setter method for the
> specified property
> PropertyDescriptor descriptor =
> getPropertyDescriptor(bean, name);
> if (descriptor == null)
> throw new NoSuchMethodException("Unknown
> property '" + name + "'");
> Method writeMethod = getWriteMethod(descriptor);
> if (writeMethod == null)
> throw new NoSuchMethodException("Property
> '" + name + "' has no setter
> method");
>
> // Call the property setter method
> Object values[] = new Object[1];
> values[0] = value;
> writeMethod.invoke(bean, values);
> }
> }
>
>
> > 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.
>
> No tag doesn't have to be changed in my way. Because all is done throught
> the Property and BeanUtils classes!!!
>
>
> > 4) Created a sub-class of ActionForm (DynamicActionForm) which
> implements
> > our "DynamicProperties" interface.
>
> No this can be done by the programmers themself just do this:
>
> public class DynamicForm extends ActionForm implements
> org.apache.struts.util.Property
>
> And then they must implement the four methods.
> Ofcourse Struts could create a default DynamicForm that uses a Hashmap for
> storing its properties
> only the getParameterTypes would be a bit difficut then! (i will
> think this
> over)
>
>
> > 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.
>
> If they just uses my interface then it is very easy to do this.
>
>
> > It would be interesting to hear others opinions on how dynamic
> properties
> > should be implemented.
>
> given :-)
>
> > Niall
>
> Johan Compagner
>
> P.S. I am willing to give my implementation of the Property interface and
> the changes to
> BeanUtils/PropertyUtils email me if you want.
>
>
>
RE: PropertyUtils Enhancement Source Code
Posted by Johan Compagner <jc...@j-com.nl>.
> 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);
Almost the samething i have now. I only have some more (and i don't have at
this time the index because
i don't believe that is nessesary, because BeanUtils / PropertyUtils are
taking care of that!
This is My interface that i use for quite sometime know.
public interface Property
{
public java.util.Map getBeanProperties(); // Is needed for the new describe
method in PropertyUtils!!
public Object getBeanProperty(String sPropertyName);
public Class[] getParameterTypes(String sName); // You should be able to get
the types of the property.
public void setBeanProperty(String sPropertyName, Object oPropertyValue);
}
> 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.
No!
ActionServlet doesn't have to change at all!!
Everychange must only be done in the PropertyUtils and BeanUtils.
What does ActionServlet to do with beans? Nothing. Struts only uses the Bean
And property utils
for filling the beans. At this time only with reflection but i changed Bean
And PropertyUtils
so that it looks for the above Interface Property and then calls the get or
set of that Property Interface.
Here some code i changed in the PropertyUtils class:
public static void setSimpleProperty(Object bean, String name, Object value)
{
// If it is of Property
if (bean instanceof Property)
{
// Use that one instead of Reflection (you create youre own reflection
interface)
((Property) bean).setBeanProperty(name, value);
}
else
{
// Retrieve the property setter method for the specified property
PropertyDescriptor descriptor = getPropertyDescriptor(bean, name);
if (descriptor == null)
throw new NoSuchMethodException("Unknown property '" + name + "'");
Method writeMethod = getWriteMethod(descriptor);
if (writeMethod == null)
throw new NoSuchMethodException("Property '" + name + "' has no setter
method");
// Call the property setter method
Object values[] = new Object[1];
values[0] = value;
writeMethod.invoke(bean, values);
}
}
> 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.
No tag doesn't have to be changed in my way. Because all is done throught
the Property and BeanUtils classes!!!
> 4) Created a sub-class of ActionForm (DynamicActionForm) which implements
> our "DynamicProperties" interface.
No this can be done by the programmers themself just do this:
public class DynamicForm extends ActionForm implements
org.apache.struts.util.Property
And then they must implement the four methods.
Ofcourse Struts could create a default DynamicForm that uses a Hashmap for
storing its properties
only the getParameterTypes would be a bit difficut then! (i will think this
over)
> 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.
If they just uses my interface then it is very easy to do this.
> It would be interesting to hear others opinions on how dynamic properties
> should be implemented.
given :-)
> Niall
Johan Compagner
P.S. I am willing to give my implementation of the Property interface and
the changes to
BeanUtils/PropertyUtils email me if you want.
RE: PropertyUtils Enhancement Source Code
Posted by Niall Pemberton <ni...@btInternet.com>.
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:dwinterfeldt@yahoo.com]
> Sent: 28 May 2001 16:59
> To: struts-dev@jakarta.apache.org
> 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 <wi...@metaconsortium.com> 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 <dw...@yahoo.com>
> > 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/
>
Re: PropertyUtils Enhancement Source Code
Posted by David Winterfeldt <dw...@yahoo.com>.
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 <wi...@metaconsortium.com> 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 <dw...@yahoo.com>
> 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/
Re: PropertyUtils Enhancement Source Code
Posted by William Shulman <wi...@metaconsortium.com>.
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 <dw...@yahoo.com> 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/
PropertyUtils Enhancement Source Code
Posted by David Winterfeldt <dw...@yahoo.com>.
Here is the source. I've done some basic tests and I
think everything is working.
David
--- David Winterfeldt <dw...@yahoo.com> 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/
Proposal to Enhance PropertyUtils
Posted by David Winterfeldt <dw...@yahoo.com>.
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/
Re: Extensions to Struts
Posted by Ted Husted <hu...@apache.org>.
Roland Huss wrote:
> In course of the development during the last three month, we made some
> extensions, which we would happily contribute to struts.
If you like, I would be happy to offer them at
< http://www.husted.com/about/struts/ >
or a link to a place where they can download them from you site.
Very soon, I hope to begin work on a place where you will be able to
upload these types of extensions and custom tags directly, so it will be
easier for Struts users to share new ideas, and help streamline the
contribution process.
Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: Extensions to Struts
Posted by richard zhang <rz...@yahoo.com>.
I am definitely interested in your extention. Please
post them or send to rzhang100@yahoo.com
Richard chang
--- Roland Huss <Ro...@consol.de> wrote:
> Ahoi,
>
> first all thanx for this real fantastic framework,
> excellent work!.
> We here at ConSol are developing a web frontend for
> our helpdesk
> software based on struts and for the time being we
> have about 30
> actions, 35 custom tags, 110 JSP-Pages (without any
> explicite java
> code!) and appr. 20k lines of Java code and it
> turned out that struts
> was a great support from the very beginning.
>
> In course of the development during the last three
> month, we made some
> extensions, which we would happily contribute to
> struts.
>
> Our extensions are listed below briefly. If there's
> some interest
> in some of them, please leave a note (note that I
> will be absent till
> wednesday in a week, so don't expect a response
> before)
>
> * Followups. Followups are a simple mechanism for an
> action to return
> to the place before it was called. Therefore we
> implemented a
> FollowupStack which is passed around in URLs and
> Forms (as hidden
> parameters). An action only needs simply to call
> "getFollowup()" in its
> perform() method to get a forward to the previous
> action. (Therefore
> FormTag and Action was extended).
>
> * Action documentation. For documentation of
> actions, we introduced
> three new javadoc tags: @input (input parameters
> expected by this
> action in its request) , @output (results put into
> request scope)
> and @forward (possible forwards of this action).
> To support these
> new tags we've written two javadoc Doclets: The
> first is extending
> the standard doclet for rendering an HTML table in
> the class
> documentation in javadoc. The other one creates
> XML-output, which we
> use with an XSL stylesheet to convert it to the
> stylebook DTD for
> the online documentation.
>
> * Hidden Parameters. Our extension of Action has an
> "addHiddenParameter()" method which put hidden
> parameters into
> request scope which our subclassed FormTag renders
> as
> HTML-Tags. With this method it is very easy to
> push parameters around
> to several actions (without polluting session
> scope).
>
> * Image Buttons. This an extension to SubmitTag for
> rendering image
> buttons and handling enabled/disabled buttons
> based on the existance
> of some object stored in request scope. Our
> actions can check for the
> trigger of a submit button regardless whether it
> was submitted as a
> submit button or an image-map.
>
> * Extra parameters in URLs. Our extended "Action"
> gives subclasses a
> change to append extra parameters to a forward by
> overriding a
> "getExtraParameters()" which will be appended to a
> forward.
>
> * From action to JSP. Not really an extension, but
> it proved for us to be
> very useful to stick to the simple paradigm, that
> a page is only
> accessed via an action and any JSP-Page is only
> referenced via an
> action. JSP pages are really only used for
> rendering the result
> calculated by the previous action, which passes
> them to the JSP page
> by putting them into request scope. Though it
> might look rather
> restrictive, this design descision proved to be
> very useful mainly
> due to its simplicity.
>
> Well, thats all I remember for the moment. We
> developed some custom
> tags, which might prove to be useful on its own (and
> not only for our
> application), but that's another story.
>
> cu....
> --
> ...roland huss
> consol.de
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/