You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jonas Björnerstedt <Jo...@iui.se> on 2001/05/30 16:55:48 UTC
Bean philosophy
Having just switched from Perl to Java web development, perhaps I am missing
something fundamental. Being new to the forum, I also don't know if this
issue has been discussed before.
It strikes me as odd that in beans in general and ActionForm beans in
particular that properties are set by setXxx and getXxx methods.
Spontaneously you would think that a bean should have a get("name") and a
set("name", "value") to retreive or save attributes in a Hashtable in the
bean.
Reusability is one of the nice things about beans. With the current design
however, if I want to retreive the properties set in a bean in a reusable
way, I have to go the roundabout way of using reflection. My question is: In
what sense is a bean more than than a Hashtable?
Here is a simple illustration of the problem. A common task I have is to
generate an SQL insert statement to save the properties of a bean. I could
for each different form have an Action class that goes through all the
getter methods to generate the SQL string. To make life simple, I derive all
my beans from a class that uses reflection to examine what fields the
derived class has, creating the SQL string in the toString method. From what
I understand, I could have used PropertyUtils instead.
Given that beans work the way they do, this is a reasonable method. But why
do things the hard way? Why not let ActionForm implement an interface with
only a get(), a set() and an getPropertyNames() method? With a Hashtable,
you could also allow the set method to add a property to the bean, something
I would find very useful.
Perhaps I have spent too much time with Perl, but to me it seems like there
is too much structure here. In looking through the literature, I have not
found any discussion of this question.
Jonas
RE: Bean philosophy
Posted by Jonas Bj�rnerstedt <jo...@bjornerstedt.org>.
> In a Been, you can use a Hashtable to save your attributes,
> but you don't have to use a Hashtable. I normaly don't.
> Because I know which attributes to expect, I implement these
> as fields in the Bean, and save the values in these. I know
> that a Hashtable has an expected constant-time on the get and
> put operations, but it is only expected time. With fields, I
> know that I have a constant-time operations, besides I'm sure
> that Java won't have to do some bookkeeping behind my back to
> insure the proper working of a Hashtable.
>
> Besides that, you can do a lot of other interesting stuff in
> the get/set methods, like accessing other objects, if you
> don't want to store the attributes in your Been.
>
> I have also been programming Perl, and I know that Hashtables
> are a nice thing. But remember, that a Java class is a proper
> class, and not just a hashtable in desguise.
>
> But of course there are situations, where what you propose is
> very usefull.
Even if a bean can do more, I thought ActionForm beans should do little.
My main question was perhaps not so clearly formulated. Why have a
cumbersome interface (getXxx() and setXxx(String val) methods) when a
simpler one could do the same job? A class with the interface
String getAttribute(String name),
void setAttribute(String name, String val) and
String [] getAttributeNames()
could do the same job as the current setup. In addition populating and
retreiving information would be simpler.
Jonas
Re: Bean philosophy
Posted by "Anders K. Olsen" <ak...@post4.tele.dk>.
----- Original Message -----
From: "Jonas Björnerstedt" <Jo...@iui.se>
To: <st...@jakarta.apache.org>
Sent: Wednesday, May 30, 2001 4:55 PM
Subject: Bean philosophy
> Having just switched from Perl to Java web development, perhaps I am missing
> something fundamental. Being new to the forum, I also don't know if this
> issue has been discussed before.
>
> It strikes me as odd that in beans in general and ActionForm beans in
> particular that properties are set by setXxx and getXxx methods.
> Spontaneously you would think that a bean should have a get("name") and a
> set("name", "value") to retreive or save attributes in a Hashtable in the
> bean.
>
> Reusability is one of the nice things about beans. With the current design
> however, if I want to retreive the properties set in a bean in a reusable
> way, I have to go the roundabout way of using reflection. My question is: In
> what sense is a bean more than than a Hashtable?
In a Been, you can use a Hashtable to save your attributes, but you don't have to use a Hashtable. I normaly don't. Because I know which attributes to expect, I implement these as fields in the Bean, and save the values in these. I know that a Hashtable has an expected constant-time on the get and put operations, but it is only expected time. With fields, I know that I have a constant-time operations, besides I'm sure that Java won't have to do some bookkeeping behind my back to insure the proper working of a Hashtable.
Besides that, you can do a lot of other interesting stuff in the get/set methods, like accessing other objects, if you don't want to store the attributes in your Been.
I have also been programming Perl, and I know that Hashtables are a nice thing. But remember, that a Java class is a proper class, and not just a hashtable in desguise.
But of course there are situations, where what you propose is very usefull.
/Anders.
Re: Bean philosophy
Posted by Taylor Cowan <tc...@silverstream.com>.
If someone were to do as you suggest, then Struts would not be adding much
to the Servlet specification, namely an HttpServletRequest. If getting
values from a hashtable is all you want, use HttpServletRequest.
HttpServletRequest is generic enough to handle all values, and like Perl,
turns everything into a String. Requests are basically just big hashtables,
and most Java developers want something a bit more specific to the data they
are receiving from the JSP page.
But the point I'm trying to make is that if you really believe what you are
saying, just forgo the entire Struts Form issue, make use of the action
mappings and forwards, and retrieve all your updates from the request
object. Have fun type casting and trying to remember the exact names of the
<input ..> fields. Be careful...one tiny mistake in capitalization or
spelling will mean you are not getting the correct property.
Taylor
----- Original Message -----
From: "Jonas Bjornerstedt" <jo...@bjornerstedt.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, May 30, 2001 2:57 PM
Subject: RE: Bean philosophy
> Although you get basic type conversion with the getter/setter methods, it
is
> not a convincing argument. The price you pay for getting something that is
> rather simple, is that 1) you have to always extend ActionForm 2) often
use
> reflection / PropertyUtils to get the information out.
>
> Wouldn't it be more logical if the ActionForm did the type conversion when
> validating rather than the Struts controller? This would be possible if
the
> interface had separate
>
> String get(String name) and
> Object getAttribute(String name)
>
> methods.
>
> Jonas
>
> > -----Original Message-----
> > From: David Winterfeldt [mailto:dwinterfeldt@yahoo.com]
> > Sent: Wednesday, May 30, 2001 5:32 PM
> > To: struts-dev@jakarta.apache.org
> > Subject: Re: Bean philosophy
> >
> >
> > I wanted to crank out a prototype of something and
> > didn't want to make all of the setter/getter methods
> > so I modified PropertyUtils to handle java.util.Map.
> > I posted some source, but other people have cleaner OO
> > implementation ideas that they have posted. Something
> > along this idea is scheduled in the Struts 1.1 To Do
> > list.
> >
> > The thread is:
> > "PropertyUtils Enhancement Source Code"
> >
> > The line blurs a little with web pages because
> > everything you get from the client are strings, but
> > setters/getters provide type checking and a standard
> > way to access methods. Struts does do basic type
> > conversions for you so you can have boolean, int,
> > double, etc. types set and it will convert the string
> > from the request object. So for checkboxes and radio
> > buttons I would use boolean and int because I know the
> > user can't enter bad data on the form. For a text
> > field that requires an int for input the field should
> > be a String in case they enter something that isn't an
> > int so you can return the value to the web form with
> > an error message. Someone else may give a better
> > explanation, but I hope this helps some.
> >
> > David
> >
> > --- Jonas_Bjvrnerstedt <Jo...@iui.se> wrote:
> > > Having just switched from Perl to Java web
> > > development, perhaps I am missing
> > > something fundamental. Being new to the forum, I
> > > also don't know if this
> > > issue has been discussed before.
> > >
> > > It strikes me as odd that in beans in general and
> > > ActionForm beans in
> > > particular that properties are set by setXxx and
> > > getXxx methods.
> > > Spontaneously you would think that a bean should
> > > have a get("name") and a
> > > set("name", "value") to retreive or save attributes
> > > in a Hashtable in the
> > > bean.
> > >
> > > Reusability is one of the nice things about beans.
> > > With the current design
> > > however, if I want to retreive the properties set in
> > > a bean in a reusable
> > > way, I have to go the roundabout way of using
> > > reflection. My question is: In
> > > what sense is a bean more than than a Hashtable?
> > >
> > > Here is a simple illustration of the problem. A
> > > common task I have is to
> > > generate an SQL insert statement to save the
> > > properties of a bean. I could
> > > for each different form have an Action class that
> > > goes through all the
> > > getter methods to generate the SQL string. To make
> > > life simple, I derive all
> > > my beans from a class that uses reflection to
> > > examine what fields the
> > > derived class has, creating the SQL string in the
> > > toString method. From what
> > > I understand, I could have used PropertyUtils
> > > instead.
> > >
> > > Given that beans work the way they do, this is a
> > > reasonable method. But why
> > > do things the hard way? Why not let ActionForm
> > > implement an interface with
> > > only a get(), a set() and an getPropertyNames()
> > > method? With a Hashtable,
> > > you could also allow the set method to add a
> > > property to the bean, something
> > > I would find very useful.
> > >
> > > Perhaps I have spent too much time with Perl, but to
> > > me it seems like there
> > > is too much structure here. In looking through the
> > > literature, I have not
> > > found any discussion of this question.
> > >
> > > Jonas
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail - only $35
> > a year! http://personal.mail.yahoo.com/
> >
Re: Bean philosophy
Posted by Johan Compagner <jc...@j-com.nl>.
> Dynamic properties are a very very very heavily requested feature, and
> will undoubtedly be addressed early in the Struts 1.1 development
> cycle. Supporting them elegantly is more than just a couple of tweaks
> here and there, so we want to make sure that we've got all the bases
> covered with our design.
hmmm.
It is working here for quite sometime now and i just inserted one Interface
and i tweaked 2 classes: BeanUtils and PropertyUtils.
So i really think the basic is a couple of tweaks.
After that maybe other people say but also this....
Johan
Re: Bean philosophy
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 30 May 2001, Jonathan Asbell wrote:
> Craig, that was the most excellent explanation.
Thanks.
> What currently IS available
> for use regarding the automatic properties, and how may I use them? I
> download the nightly builds ;^>
There's nothing in the "official" builds at the moment -- even the nightly
ones. Ted's page (available via the "Resources" link at
<http://jakarta.apache.org/struts>) has links to some of the available
approaches. You can also search the mailing list archives for messages
related to this topic. I've been trying to catch up on STRUTS-USER mail,
and it seems to be by far the most common request -- guess we'd better pay
attention after 1.0 goes final :-).
Craig
Re: Bean philosophy
Posted by Jonathan Asbell <ja...@i-2000.com>.
Craig, that was the most excellent explanation. What currently IS available
for use regarding the automatic properties, and how may I use them? I
download the nightly builds ;^>
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>; <jo...@bjornerstedt.org>
Sent: Wednesday, May 30, 2001 4:14 PM
Subject: RE: Bean philosophy
>
>
> On Wed, 30 May 2001, Jonas Bjornerstedt wrote:
>
> > Although you get basic type conversion with the getter/setter methods,
it is
> > not a convincing argument. The price you pay for getting something that
is
> > rather simple, is that 1) you have to always extend ActionForm 2) often
use
> > reflection / PropertyUtils to get the information out.
> >
> > Wouldn't it be more logical if the ActionForm did the type conversion
when
> > validating rather than the Struts controller? This would be possible if
the
> > interface had separate
> >
> > String get(String name) and
> > Object getAttribute(String name)
> >
> > methods.
> >
>
>
> Hello Jonas,
>
> I think you've really got two threads of questions here, so let me try to
> address them separately.
>
> (1) Why use getXxx and setXxx for properties?
>
> This is a general design pattern called JavaBeans, and you will find it
> very commonly implemented. There's a specification that documents these
> conventions, available at:
>
> http://java.sun.com/products/javabeans/docs/spec.html
>
> but the basic principles revolve around:
>
> * Information hiding (for example, how do *you* know that a
> particular getter method returns a simple property value,
> and doesn't do some on-the-fly calculations every time?)
>
> * Introspection (so that development tools can recognize the
> design patterns and provide a nice GUI user interface for
> creating and connecting beans).
>
> Dynamic properties are a very very very heavily requested feature, and
> will undoubtedly be addressed early in the Struts 1.1 development
> cycle. Supporting them elegantly is more than just a couple of tweaks
> here and there, so we want to make sure that we've got all the bases
> covered with our design.
>
> In the mean time, though, you'll see the JavaBeans naming patterns used
> almost universally in Java programming, so it's well worth your time to
> learn them and start using them.
>
> (2) Why ActionForm versus just ordinary beans?
>
> This is a deliberate and fundamental design decision that I made when
> first designing Struts. The short answer is that, IMHO, form beans are
> part of the View layer in an MVC architecture, not the Model layer. This
> is based on the following principles:
>
> * When the user enters invalid data, the application needs to be
> able to redisplay what the user last entered (even if it was wrong),
> along with the error messages, so that the user doesn't have to
> retype everything again. Would *you* ever use a web application
> that didn't have this property?
>
> * In order to do this in a web application, there needs to be some
> representation of the current input state from the user's last form
> submit (again, even if it's wrong). So it doesn't make sense to try
> to use the "real" JavaBeans that actually represent your data. Consider
> an integer field, where the user typed in "1A3" instead of "123". If
> you're using a "real" data object, you get an input conversion error --
> and NO WAY to reproduce what the last input again. You need a separate
> object anyway.
>
> * In addition, Struts supports the optional concept of calling a
> validate() method for you. Thus, there needed to be some Java API
> for form beans anyway -- either an interface or a class -- so that
> the controller servlet can recognize when to do it. Originally
> ActionForm was an interface, but that made every Struts application
> fragile in the face of later enhancements -- adding a new public
> method to the ActionForm interface would break every single existing
> form bean in every single Struts based application, and that would not
> be very popular :-). Therefore, we use a base class instead.
>
> * You can, of course, use the underlying BeanUtils.populate() method
> yourself to populate any arbitrary object. It's just that Struts won't
> give you the other automatic support it does for ActionForm beans.
>
> > Jonas
> >
>
> Craig McClanahan
>
>
> > > -----Original Message-----
> > > From: David Winterfeldt [mailto:dwinterfeldt@yahoo.com]
> > > Sent: Wednesday, May 30, 2001 5:32 PM
> > > To: struts-dev@jakarta.apache.org
> > > Subject: Re: Bean philosophy
> > >
> > >
> > > I wanted to crank out a prototype of something and
> > > didn't want to make all of the setter/getter methods
> > > so I modified PropertyUtils to handle java.util.Map.
> > > I posted some source, but other people have cleaner OO
> > > implementation ideas that they have posted. Something
> > > along this idea is scheduled in the Struts 1.1 To Do
> > > list.
> > >
> > > The thread is:
> > > "PropertyUtils Enhancement Source Code"
> > >
> > > The line blurs a little with web pages because
> > > everything you get from the client are strings, but
> > > setters/getters provide type checking and a standard
> > > way to access methods. Struts does do basic type
> > > conversions for you so you can have boolean, int,
> > > double, etc. types set and it will convert the string
> > > from the request object. So for checkboxes and radio
> > > buttons I would use boolean and int because I know the
> > > user can't enter bad data on the form. For a text
> > > field that requires an int for input the field should
> > > be a String in case they enter something that isn't an
> > > int so you can return the value to the web form with
> > > an error message. Someone else may give a better
> > > explanation, but I hope this helps some.
> > >
> > > David
> > >
> > > --- Jonas_Bjvrnerstedt <Jo...@iui.se> wrote:
> > > > Having just switched from Perl to Java web
> > > > development, perhaps I am missing
> > > > something fundamental. Being new to the forum, I
> > > > also don't know if this
> > > > issue has been discussed before.
> > > >
> > > > It strikes me as odd that in beans in general and
> > > > ActionForm beans in
> > > > particular that properties are set by setXxx and
> > > > getXxx methods.
> > > > Spontaneously you would think that a bean should
> > > > have a get("name") and a
> > > > set("name", "value") to retreive or save attributes
> > > > in a Hashtable in the
> > > > bean.
> > > >
> > > > Reusability is one of the nice things about beans.
> > > > With the current design
> > > > however, if I want to retreive the properties set in
> > > > a bean in a reusable
> > > > way, I have to go the roundabout way of using
> > > > reflection. My question is: In
> > > > what sense is a bean more than than a Hashtable?
> > > >
> > > > Here is a simple illustration of the problem. A
> > > > common task I have is to
> > > > generate an SQL insert statement to save the
> > > > properties of a bean. I could
> > > > for each different form have an Action class that
> > > > goes through all the
> > > > getter methods to generate the SQL string. To make
> > > > life simple, I derive all
> > > > my beans from a class that uses reflection to
> > > > examine what fields the
> > > > derived class has, creating the SQL string in the
> > > > toString method. From what
> > > > I understand, I could have used PropertyUtils
> > > > instead.
> > > >
> > > > Given that beans work the way they do, this is a
> > > > reasonable method. But why
> > > > do things the hard way? Why not let ActionForm
> > > > implement an interface with
> > > > only a get(), a set() and an getPropertyNames()
> > > > method? With a Hashtable,
> > > > you could also allow the set method to add a
> > > > property to the bean, something
> > > > I would find very useful.
> > > >
> > > > Perhaps I have spent too much time with Perl, but to
> > > > me it seems like there
> > > > is too much structure here. In looking through the
> > > > literature, I have not
> > > > found any discussion of this question.
> > > >
> > > > Jonas
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get personalized email addresses from Yahoo! Mail - only $35
> > > a year! http://personal.mail.yahoo.com/
> > >
> >
> >
>
Re: Bean philosophy
Posted by Ted Husted <hu...@apache.org>.
You can check the latest version of Strut by Strut. There are some
"stub" versions of what I use for value object there. Though, my
implementation is rather straight-forward, since I am not trying to hook
these up with enterprise beans, just use the same general design
pattern.
As a convenience, I've started to merge the data access object into the
value object bean, so that the value bean knows how to insert, select,
update, or delete itself. (But only through internal methods, there are
no public mutators on the value beans.) The data access is provided via
an "Accessible" interface to keep a clear distinction between the value
methods and the data access methods. Likewise, I would also added
another interface to represent and seperate business logic that needed
to use this data.
Again, the core idea is to simply use ActionForm beans to get stuff on
and off HTML forms, and then use your own framework-independant beans
for everything else.
Jonathan Asbell wrote:
>
> Great explanation Ted. I am interested in your implementation of the
> ValueObjects. It appears as though you dont use the ActionForm as a value
> object, but rather pass the ActionForm beans values on to the value object
> after validating symantics in the Action. Is this true? I ask because I
> have read 3-4 different ways to implement the value object, and I am
> interested in what works best with struts. You remember the comment by
> Bryan Field-Elliot? He wrote me with his implementation which he felt he
> still had to work out some issues with hiding some data from other classes.
> I then read an interesting idea at theserverside.com
> http://www.theserverside.com/patterns/thread.jsp?thread_id=2722 and another
> version http://www.theserverside.com/patterns/depbmp.jsp.
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, May 30, 2001 10:38 PM
> Subject: Re: Bean philosophy
>
> > Jonas Bjornerstedt wrote:
> > > I see little reason (yet) why the ActionForm should be modeled as such.
> >
> > I think the keyword here is "yet". Much of the underlying Struts designs
> > are based on trends and patterns that have yet to reach their logical
> > conclusion.
> >
> > For example, future Java design tools are sure to fully support
> > JavaBeans. Support for other structures, like hashtables, is likely to
> > be less thorough. Another example is custom tags, which are a good thing
> > now, but will be a truly tremendous thing when the visual HTML editors
> > catch up with the Java 2 spec.
> >
> > Struts is also designed to work well with J2EE design patterns, which
> > rely on JavaBeans. I construct both my form and model (or value) beans
> > at the same time (using simple search and replace templates), and then
> > extend the value beans to work with native types. Personally, I find it
> > more convenient to be working with beans on both sides, rather than with
> > a hashtable here and a JavaBean there.
> >
> > It is also very important to note that the ActionForm beans are just a
> > means to an end. They exist as an adaptor between the HTML forms and the
> > rest of your application. After the data has been captured, it should be
> > handed to another object to handle the business-logic portion of your
> > program. As such, they are usually only persistent for the life of a
> > request, and as you say, should do little beside validating the input
> > and converting the data for use by another object.
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 737-3463.
> > -- http://www.husted.com/about/struts/
> >
Re: Bean philosophy
Posted by Ted Husted <hu...@apache.org>.
You can check the latest version of Strut by Strut. There are some
"stub" versions of what I use for value object there. Though, my
implementation is rather straight-forward, since I am not trying to hook
these up with enterprise beans, just use the same general design
pattern.
As a convenience, I've started to merge the data access object into the
value object bean, so that the value bean knows how to insert, select,
update, or delete itself. (But only through internal methods, there are
no public mutators on the value beans.) The data access is provided via
an "Accessible" interface to keep a clear distinction between the value
methods and the data access methods. Likewise, I would also added
another interface to represent and seperate business logic that needed
to use this data.
Again, the core idea is to simply use ActionForm beans to get stuff on
and off HTML forms, and then use your own framework-independant beans
for everything else.
Jonathan Asbell wrote:
>
> Great explanation Ted. I am interested in your implementation of the
> ValueObjects. It appears as though you dont use the ActionForm as a value
> object, but rather pass the ActionForm beans values on to the value object
> after validating symantics in the Action. Is this true? I ask because I
> have read 3-4 different ways to implement the value object, and I am
> interested in what works best with struts. You remember the comment by
> Bryan Field-Elliot? He wrote me with his implementation which he felt he
> still had to work out some issues with hiding some data from other classes.
> I then read an interesting idea at theserverside.com
> http://www.theserverside.com/patterns/thread.jsp?thread_id=2722 and another
> version http://www.theserverside.com/patterns/depbmp.jsp.
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, May 30, 2001 10:38 PM
> Subject: Re: Bean philosophy
>
> > Jonas Bjornerstedt wrote:
> > > I see little reason (yet) why the ActionForm should be modeled as such.
> >
> > I think the keyword here is "yet". Much of the underlying Struts designs
> > are based on trends and patterns that have yet to reach their logical
> > conclusion.
> >
> > For example, future Java design tools are sure to fully support
> > JavaBeans. Support for other structures, like hashtables, is likely to
> > be less thorough. Another example is custom tags, which are a good thing
> > now, but will be a truly tremendous thing when the visual HTML editors
> > catch up with the Java 2 spec.
> >
> > Struts is also designed to work well with J2EE design patterns, which
> > rely on JavaBeans. I construct both my form and model (or value) beans
> > at the same time (using simple search and replace templates), and then
> > extend the value beans to work with native types. Personally, I find it
> > more convenient to be working with beans on both sides, rather than with
> > a hashtable here and a JavaBean there.
> >
> > It is also very important to note that the ActionForm beans are just a
> > means to an end. They exist as an adaptor between the HTML forms and the
> > rest of your application. After the data has been captured, it should be
> > handed to another object to handle the business-logic portion of your
> > program. As such, they are usually only persistent for the life of a
> > request, and as you say, should do little beside validating the input
> > and converting the data for use by another object.
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 737-3463.
> > -- http://www.husted.com/about/struts/
> >
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: String indexed bean fields
Posted by Ted Husted <hu...@apache.org>.
So, would this then give us access to things like RowSet objects which
have accessors like getString(1) ?
"Craig R. McClanahan" wrote:
> Yep. Something like this is part of the enhancements I see in Struts 1.1.
> On Wed, 30 May 2001, Rapheal Kaplan wrote:
> > Has anyone thought about allowing for string based indexed fields (even
> > though they do not fit in to the Java spec)?
> > For example:
> > <logic:write name="user" property="email{home}"/>
> > would call:
> > user.getEmail( "home" );
> > - Rapheal Kaplan
Re: String indexed bean fields
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 30 May 2001, Rapheal Kaplan wrote:
> Has anyone thought about allowing for string based indexed fields (even
> though they do not fit in to the Java spec)?
>
> For example:
>
> <logic:write name="user" property="email{home}"/>
>
> would call:
>
> user.getEmail( "home" );
>
>
> - Rapheal Kaplan
>
>
Yep. Something like this is part of the enhancements I see in Struts 1.1.
Craig
String indexed bean fields
Posted by Rapheal Kaplan <ra...@mimir.net>.
Has anyone thought about allowing for string based indexed fields (even
though they do not fit in to the Java spec)?
For example:
<logic:write name="user" property="email{home}"/>
would call:
user.getEmail( "home" );
- Rapheal Kaplan
Re: Bean philosophy
Posted by Jonathan Asbell <ja...@i-2000.com>.
Great explanation Ted. I am interested in your implementation of the
ValueObjects. It appears as though you dont use the ActionForm as a value
object, but rather pass the ActionForm beans values on to the value object
after validating symantics in the Action. Is this true? I ask because I
have read 3-4 different ways to implement the value object, and I am
interested in what works best with struts. You remember the comment by
Bryan Field-Elliot? He wrote me with his implementation which he felt he
still had to work out some issues with hiding some data from other classes.
I then read an interesting idea at theserverside.com
http://www.theserverside.com/patterns/thread.jsp?thread_id=2722 and another
version http://www.theserverside.com/patterns/depbmp.jsp.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, May 30, 2001 10:38 PM
Subject: Re: Bean philosophy
> Jonas Bjornerstedt wrote:
> > I see little reason (yet) why the ActionForm should be modeled as such.
>
> I think the keyword here is "yet". Much of the underlying Struts designs
> are based on trends and patterns that have yet to reach their logical
> conclusion.
>
> For example, future Java design tools are sure to fully support
> JavaBeans. Support for other structures, like hashtables, is likely to
> be less thorough. Another example is custom tags, which are a good thing
> now, but will be a truly tremendous thing when the visual HTML editors
> catch up with the Java 2 spec.
>
> Struts is also designed to work well with J2EE design patterns, which
> rely on JavaBeans. I construct both my form and model (or value) beans
> at the same time (using simple search and replace templates), and then
> extend the value beans to work with native types. Personally, I find it
> more convenient to be working with beans on both sides, rather than with
> a hashtable here and a JavaBean there.
>
> It is also very important to note that the ActionForm beans are just a
> means to an end. They exist as an adaptor between the HTML forms and the
> rest of your application. After the data has been captured, it should be
> handed to another object to handle the business-logic portion of your
> program. As such, they are usually only persistent for the life of a
> request, and as you say, should do little beside validating the input
> and converting the data for use by another object.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
Re: Bean philosophy
Posted by Ted Husted <hu...@apache.org>.
Jonas Bjornerstedt wrote:
> I see little reason (yet) why the ActionForm should be modeled as such.
I think the keyword here is "yet". Much of the underlying Struts designs
are based on trends and patterns that have yet to reach their logical
conclusion.
For example, future Java design tools are sure to fully support
JavaBeans. Support for other structures, like hashtables, is likely to
be less thorough. Another example is custom tags, which are a good thing
now, but will be a truly tremendous thing when the visual HTML editors
catch up with the Java 2 spec.
Struts is also designed to work well with J2EE design patterns, which
rely on JavaBeans. I construct both my form and model (or value) beans
at the same time (using simple search and replace templates), and then
extend the value beans to work with native types. Personally, I find it
more convenient to be working with beans on both sides, rather than with
a hashtable here and a JavaBean there.
It is also very important to note that the ActionForm beans are just a
means to an end. They exist as an adaptor between the HTML forms and the
rest of your application. After the data has been captured, it should be
handed to another object to handle the business-logic portion of your
program. As such, they are usually only persistent for the life of a
request, and as you say, should do little beside validating the input
and converting the data for use by another object.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
RE: Bean philosophy
Posted by Jonas Bjornerstedt <jo...@bjornerstedt.org>.
Thanks for taking some time to answer my "naiive question.
>
> I think you've really got two threads of questions here, so
> let me try to
> address them separately.
>
> (1) Why use getXxx and setXxx for properties?
>
> This is a general design pattern called JavaBeans, and you
> will find it very commonly implemented.
Yes, I know. The question that I was asking though, was why implement the
JavaBeans design pattern here? A persistent class in a web setting does not
have to be a bean. A ServletContext or a HttpSession is not. Attributes are
set and retreived along the lines I indicated. Although JavaBeans have been
one way of getting persistence, I see little reason (yet) why the ActionForm
should be modeled as such.
> * Information hiding (for example, how do *you* know that a
> particular getter method returns a simple property value,
> and doesn't do some on-the-fly calculations every time?)
Beside the point, information is as hidden with the simpler interface.
> * Introspection (so that development tools can recognize the
> design patterns and provide a nice GUI user interface for
> creating and connecting beans).
Nothing prevents the programmer from adding getter/setter methods for the
Action class by extending the ActionForm class.
> (2) Why ActionForm versus just ordinary beans?
My question was why ActionForm is modeled on a bean, not why it should be
the base class. In the end, the design of a class should depend on what
designers think it should do. The point of departure in my philosophising
was that ActionForm should do little beyond conversions, validations and
such.
Jonas
RE: Bean philosophy
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 30 May 2001, Jonas Bjornerstedt wrote:
> Although you get basic type conversion with the getter/setter methods, it is
> not a convincing argument. The price you pay for getting something that is
> rather simple, is that 1) you have to always extend ActionForm 2) often use
> reflection / PropertyUtils to get the information out.
>
> Wouldn't it be more logical if the ActionForm did the type conversion when
> validating rather than the Struts controller? This would be possible if the
> interface had separate
>
> String get(String name) and
> Object getAttribute(String name)
>
> methods.
>
Hello Jonas,
I think you've really got two threads of questions here, so let me try to
address them separately.
(1) Why use getXxx and setXxx for properties?
This is a general design pattern called JavaBeans, and you will find it
very commonly implemented. There's a specification that documents these
conventions, available at:
http://java.sun.com/products/javabeans/docs/spec.html
but the basic principles revolve around:
* Information hiding (for example, how do *you* know that a
particular getter method returns a simple property value,
and doesn't do some on-the-fly calculations every time?)
* Introspection (so that development tools can recognize the
design patterns and provide a nice GUI user interface for
creating and connecting beans).
Dynamic properties are a very very very heavily requested feature, and
will undoubtedly be addressed early in the Struts 1.1 development
cycle. Supporting them elegantly is more than just a couple of tweaks
here and there, so we want to make sure that we've got all the bases
covered with our design.
In the mean time, though, you'll see the JavaBeans naming patterns used
almost universally in Java programming, so it's well worth your time to
learn them and start using them.
(2) Why ActionForm versus just ordinary beans?
This is a deliberate and fundamental design decision that I made when
first designing Struts. The short answer is that, IMHO, form beans are
part of the View layer in an MVC architecture, not the Model layer. This
is based on the following principles:
* When the user enters invalid data, the application needs to be
able to redisplay what the user last entered (even if it was wrong),
along with the error messages, so that the user doesn't have to
retype everything again. Would *you* ever use a web application
that didn't have this property?
* In order to do this in a web application, there needs to be some
representation of the current input state from the user's last form
submit (again, even if it's wrong). So it doesn't make sense to try
to use the "real" JavaBeans that actually represent your data. Consider
an integer field, where the user typed in "1A3" instead of "123". If
you're using a "real" data object, you get an input conversion error --
and NO WAY to reproduce what the last input again. You need a separate
object anyway.
* In addition, Struts supports the optional concept of calling a
validate() method for you. Thus, there needed to be some Java API
for form beans anyway -- either an interface or a class -- so that
the controller servlet can recognize when to do it. Originally
ActionForm was an interface, but that made every Struts application
fragile in the face of later enhancements -- adding a new public
method to the ActionForm interface would break every single existing
form bean in every single Struts based application, and that would not
be very popular :-). Therefore, we use a base class instead.
* You can, of course, use the underlying BeanUtils.populate() method
yourself to populate any arbitrary object. It's just that Struts won't
give you the other automatic support it does for ActionForm beans.
> Jonas
>
Craig McClanahan
> > -----Original Message-----
> > From: David Winterfeldt [mailto:dwinterfeldt@yahoo.com]
> > Sent: Wednesday, May 30, 2001 5:32 PM
> > To: struts-dev@jakarta.apache.org
> > Subject: Re: Bean philosophy
> >
> >
> > I wanted to crank out a prototype of something and
> > didn't want to make all of the setter/getter methods
> > so I modified PropertyUtils to handle java.util.Map.
> > I posted some source, but other people have cleaner OO
> > implementation ideas that they have posted. Something
> > along this idea is scheduled in the Struts 1.1 To Do
> > list.
> >
> > The thread is:
> > "PropertyUtils Enhancement Source Code"
> >
> > The line blurs a little with web pages because
> > everything you get from the client are strings, but
> > setters/getters provide type checking and a standard
> > way to access methods. Struts does do basic type
> > conversions for you so you can have boolean, int,
> > double, etc. types set and it will convert the string
> > from the request object. So for checkboxes and radio
> > buttons I would use boolean and int because I know the
> > user can't enter bad data on the form. For a text
> > field that requires an int for input the field should
> > be a String in case they enter something that isn't an
> > int so you can return the value to the web form with
> > an error message. Someone else may give a better
> > explanation, but I hope this helps some.
> >
> > David
> >
> > --- Jonas_Bjvrnerstedt <Jo...@iui.se> wrote:
> > > Having just switched from Perl to Java web
> > > development, perhaps I am missing
> > > something fundamental. Being new to the forum, I
> > > also don't know if this
> > > issue has been discussed before.
> > >
> > > It strikes me as odd that in beans in general and
> > > ActionForm beans in
> > > particular that properties are set by setXxx and
> > > getXxx methods.
> > > Spontaneously you would think that a bean should
> > > have a get("name") and a
> > > set("name", "value") to retreive or save attributes
> > > in a Hashtable in the
> > > bean.
> > >
> > > Reusability is one of the nice things about beans.
> > > With the current design
> > > however, if I want to retreive the properties set in
> > > a bean in a reusable
> > > way, I have to go the roundabout way of using
> > > reflection. My question is: In
> > > what sense is a bean more than than a Hashtable?
> > >
> > > Here is a simple illustration of the problem. A
> > > common task I have is to
> > > generate an SQL insert statement to save the
> > > properties of a bean. I could
> > > for each different form have an Action class that
> > > goes through all the
> > > getter methods to generate the SQL string. To make
> > > life simple, I derive all
> > > my beans from a class that uses reflection to
> > > examine what fields the
> > > derived class has, creating the SQL string in the
> > > toString method. From what
> > > I understand, I could have used PropertyUtils
> > > instead.
> > >
> > > Given that beans work the way they do, this is a
> > > reasonable method. But why
> > > do things the hard way? Why not let ActionForm
> > > implement an interface with
> > > only a get(), a set() and an getPropertyNames()
> > > method? With a Hashtable,
> > > you could also allow the set method to add a
> > > property to the bean, something
> > > I would find very useful.
> > >
> > > Perhaps I have spent too much time with Perl, but to
> > > me it seems like there
> > > is too much structure here. In looking through the
> > > literature, I have not
> > > found any discussion of this question.
> > >
> > > Jonas
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail - only $35
> > a year! http://personal.mail.yahoo.com/
> >
>
>
RE: Bean philosophy
Posted by Jonas Bjornerstedt <jo...@bjornerstedt.org>.
Although you get basic type conversion with the getter/setter methods, it is
not a convincing argument. The price you pay for getting something that is
rather simple, is that 1) you have to always extend ActionForm 2) often use
reflection / PropertyUtils to get the information out.
Wouldn't it be more logical if the ActionForm did the type conversion when
validating rather than the Struts controller? This would be possible if the
interface had separate
String get(String name) and
Object getAttribute(String name)
methods.
Jonas
> -----Original Message-----
> From: David Winterfeldt [mailto:dwinterfeldt@yahoo.com]
> Sent: Wednesday, May 30, 2001 5:32 PM
> To: struts-dev@jakarta.apache.org
> Subject: Re: Bean philosophy
>
>
> I wanted to crank out a prototype of something and
> didn't want to make all of the setter/getter methods
> so I modified PropertyUtils to handle java.util.Map.
> I posted some source, but other people have cleaner OO
> implementation ideas that they have posted. Something
> along this idea is scheduled in the Struts 1.1 To Do
> list.
>
> The thread is:
> "PropertyUtils Enhancement Source Code"
>
> The line blurs a little with web pages because
> everything you get from the client are strings, but
> setters/getters provide type checking and a standard
> way to access methods. Struts does do basic type
> conversions for you so you can have boolean, int,
> double, etc. types set and it will convert the string
> from the request object. So for checkboxes and radio
> buttons I would use boolean and int because I know the
> user can't enter bad data on the form. For a text
> field that requires an int for input the field should
> be a String in case they enter something that isn't an
> int so you can return the value to the web form with
> an error message. Someone else may give a better
> explanation, but I hope this helps some.
>
> David
>
> --- Jonas_Bjvrnerstedt <Jo...@iui.se> wrote:
> > Having just switched from Perl to Java web
> > development, perhaps I am missing
> > something fundamental. Being new to the forum, I
> > also don't know if this
> > issue has been discussed before.
> >
> > It strikes me as odd that in beans in general and
> > ActionForm beans in
> > particular that properties are set by setXxx and
> > getXxx methods.
> > Spontaneously you would think that a bean should
> > have a get("name") and a
> > set("name", "value") to retreive or save attributes
> > in a Hashtable in the
> > bean.
> >
> > Reusability is one of the nice things about beans.
> > With the current design
> > however, if I want to retreive the properties set in
> > a bean in a reusable
> > way, I have to go the roundabout way of using
> > reflection. My question is: In
> > what sense is a bean more than than a Hashtable?
> >
> > Here is a simple illustration of the problem. A
> > common task I have is to
> > generate an SQL insert statement to save the
> > properties of a bean. I could
> > for each different form have an Action class that
> > goes through all the
> > getter methods to generate the SQL string. To make
> > life simple, I derive all
> > my beans from a class that uses reflection to
> > examine what fields the
> > derived class has, creating the SQL string in the
> > toString method. From what
> > I understand, I could have used PropertyUtils
> > instead.
> >
> > Given that beans work the way they do, this is a
> > reasonable method. But why
> > do things the hard way? Why not let ActionForm
> > implement an interface with
> > only a get(), a set() and an getPropertyNames()
> > method? With a Hashtable,
> > you could also allow the set method to add a
> > property to the bean, something
> > I would find very useful.
> >
> > Perhaps I have spent too much time with Perl, but to
> > me it seems like there
> > is too much structure here. In looking through the
> > literature, I have not
> > found any discussion of this question.
> >
> > Jonas
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
Re: Bean philosophy
Posted by David Winterfeldt <dw...@yahoo.com>.
I wanted to crank out a prototype of something and
didn't want to make all of the setter/getter methods
so I modified PropertyUtils to handle java.util.Map.
I posted some source, but other people have cleaner OO
implementation ideas that they have posted. Something
along this idea is scheduled in the Struts 1.1 To Do
list.
The thread is:
"PropertyUtils Enhancement Source Code"
The line blurs a little with web pages because
everything you get from the client are strings, but
setters/getters provide type checking and a standard
way to access methods. Struts does do basic type
conversions for you so you can have boolean, int,
double, etc. types set and it will convert the string
from the request object. So for checkboxes and radio
buttons I would use boolean and int because I know the
user can't enter bad data on the form. For a text
field that requires an int for input the field should
be a String in case they enter something that isn't an
int so you can return the value to the web form with
an error message. Someone else may give a better
explanation, but I hope this helps some.
David
--- Jonas_Bj�rnerstedt <Jo...@iui.se> wrote:
> Having just switched from Perl to Java web
> development, perhaps I am missing
> something fundamental. Being new to the forum, I
> also don't know if this
> issue has been discussed before.
>
> It strikes me as odd that in beans in general and
> ActionForm beans in
> particular that properties are set by setXxx and
> getXxx methods.
> Spontaneously you would think that a bean should
> have a get("name") and a
> set("name", "value") to retreive or save attributes
> in a Hashtable in the
> bean.
>
> Reusability is one of the nice things about beans.
> With the current design
> however, if I want to retreive the properties set in
> a bean in a reusable
> way, I have to go the roundabout way of using
> reflection. My question is: In
> what sense is a bean more than than a Hashtable?
>
> Here is a simple illustration of the problem. A
> common task I have is to
> generate an SQL insert statement to save the
> properties of a bean. I could
> for each different form have an Action class that
> goes through all the
> getter methods to generate the SQL string. To make
> life simple, I derive all
> my beans from a class that uses reflection to
> examine what fields the
> derived class has, creating the SQL string in the
> toString method. From what
> I understand, I could have used PropertyUtils
> instead.
>
> Given that beans work the way they do, this is a
> reasonable method. But why
> do things the hard way? Why not let ActionForm
> implement an interface with
> only a get(), a set() and an getPropertyNames()
> method? With a Hashtable,
> you could also allow the set method to add a
> property to the bean, something
> I would find very useful.
>
> Perhaps I have spent too much time with Perl, but to
> me it seems like there
> is too much structure here. In looking through the
> literature, I have not
> found any discussion of this question.
>
> Jonas
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/