You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Kevin Duffey <kd...@buymedia.com> on 2000/08/23 05:18:52 UTC
Override auto-population feature of Struts (repost)?
Hi,
I am wondering if its possible to override or extend the part of Struts that
handles (or is called) auto-population of beans from form elements. We have
a "foundation" of classes that are basically beans, and it would be
wonderful if we could not have to create many get/set methods in beans that
basically typecast an "entity" object field in each bean to the specific
type of object the bean will model. For example, we have something like so:
public class Buyer
{
private String firstName = "";
private String lastName = "";
public Buyer()
{
}
public String getFirstName()
{
return firstName;
}
public String getLastName()
{
return lastName;
}
public void setFirstName(String value)
{
firstName = value;
}
public void setLastName(String value)
{
lastName = value;
}
}
This is part of our core package that many of our web apps use. However,
these are core classes that will not implement the Action interface (thus be
dependont on struts.jar to work). Instead, I am wondering if there is some
way to get the auot-population feature to just use the "core" beans and
populate their fields directly, without having to do the following:
public class SomeBean
implements Action
{
private Object entity = null;
public SomeBean()
{
entity = new Buyer();
}
public String getFirstName()
{
return ( (Buyer) entity).getFirstName();
}
public String getLastName()
{
return ( (Buyer) entity).getLastName();
}
public void setFirstName(String value)
{
( (Buyer) entity).setFirstName(value);
}
public void setLastName(String value)
{
( (Buyer) entity).setLastName(value);
}
}
While I don't see a big deal with the approach I have taken, I am not sure
if the type-casting slows things down, and if it would be faster just to
directly populate a Buyer object. Is there a reason the bean must implement
the Action interface?
Thanks.
Override auto-population feature of Struts (repost)?
Posted by Nick Afshartous <af...@iclick.com>.
Kevin Duffey writes:
> public class SomeBean
> implements Action
> {
> private Object entity = null;
>
> public SomeBean()
> {
> entity = new Buyer();
> }
>
> public String getFirstName()
> {
> return ( (Buyer) entity).getFirstName();
> }
>
> public String getLastName()
> {
> return ( (Buyer) entity).getLastName();
> }
>
> public void setFirstName(String value)
> {
> ( (Buyer) entity).setFirstName(value);
> }
>
> public void setLastName(String value)
> {
> ( (Buyer) entity).setLastName(value);
> }
> }
>
>
> While I don't see a big deal with the approach I have taken, I am not sure
> if the type-casting slows things down, and if it would be faster just to
> directly populate a Buyer object.
A type-cast introduces a run-time type-check so it is extra
overhead. In addition type-casts are unsafe in that
there are no guarantees the cast will not fail at run-time.
Several proposals have been made to incorporate
parametric polymorphism (i.e. a C++ template-like facility) into
Java that would alleviate the need for most type-casts. I'm
not up on the latest status of the proposals though.
--
Nick
Re: A new attribute for struts' button tags
Posted by Chris Miller <ki...@vardus.co.uk>.
Sounds fine by me. In fact, something very similar is the 'readonly'
attribute that the input tags could probably use as well.(Yes I realise
Netscape ignores the 'disabled' attribute, but it's part of the HTML spec).
Also Craig, as an aside, did you get a chance to look at the checkbox
management code I posted a couple of days ago? It shouldn't break backwards
compatibility, so even though it doesn't work in all circumstances (eg
multiple checkboxes mapped to a single name), I feel it is useful enough as
it stands to be included into struts.
Some more bits and pieces:
A bug(?) that I noticed... The 'cancel' tag has a property value. However
setting this then means that the button behaves like a normal submit button
(validation is performed on the validatingActionForm etc). Perhaps this
attribute should be removed since it is quite confusing? (I can't see a
clean workaround to keep it in and let the cancel button still behave
correctly, although it would be nice if this were possible).
I have noticed a couple of holes in the documentation too:
I can't see any documentation for how the prefix/suffix matching works? I
can't quite figure it out.
No docs for ifPropertyEquals / ifPropertyNotEquals tags.
No docs for encodeRedirectURL / encodeURL tags.
The example for the iterate tag doesn't actually work.
Chris
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, August 23, 2000 4:29 PM
Subject: Re: A new attribute for struts' button tags
>
>
> Chris Miller wrote:
>
> > I was wondering if it would be possible to add a new attribute to the
> > submit, cancel and button tags - disabled="true" to disable the button.
I
> > would like this because I have a multi-part form, and want to
selectively
> > disable the 'back', 'next' and 'finish' buttons.
>
> That makes sense, but it raises a question. Isn't the "disabled"
attribute
> available on lots of the other tags as well (like "input")? It would seem
to
> make sense to have the disabled option on all of them, not just the
buttons.
>
> Craig
>
>
>
Re: A new attribute for struts' button tags
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Chris Miller wrote:
> I was wondering if it would be possible to add a new attribute to the
> submit, cancel and button tags - disabled="true" to disable the button. I
> would like this because I have a multi-part form, and want to selectively
> disable the 'back', 'next' and 'finish' buttons.
That makes sense, but it raises a question. Isn't the "disabled" attribute
available on lots of the other tags as well (like "input")? It would seem to
make sense to have the disabled option on all of them, not just the buttons.
Craig
A new attribute for struts' button tags
Posted by Chris Miller <ki...@vardus.co.uk>.
I was wondering if it would be possible to add a new attribute to the
submit, cancel and button tags - disabled="true" to disable the button. I
would like this because I have a multi-part form, and want to selectively
disable the 'back', 'next' and 'finish' buttons.
RE: Override auto-population feature of Struts (repost)?
Posted by Kevin Duffey <kd...@buymedia.com>.
Thats a great idea. As I wrote to Craig (and the struts community), I think
what my co-worker has done is pretty cool. The ability to populate nested
objects in a class based on the form element name have the same name as the
object field gives the ability to easily customize auto-population of beans
without the need to write getter/setter methods that do just that anyways.
It saves on having to recode the same getter/setter method in one bean that
populates a field of a nested object in itself already.
Craig/Eduardo..what do you think? Is it too late to see this put in to JSP
1.2/Servlet 2.3?
> -----Original Message-----
> From: Eduardo Pelegri--Llopart
> [mailto:Eduardo.Pelegrillopart@eng.sun.com]
> Sent: Wednesday, August 23, 2000 12:25 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Override auto-population feature of Struts (repost)?
>
>
> If the struts community feels the need for this, perhaps somebody could
> compose a proposal for exntending the base jsp:setProperty and
> jsp:getProperty mechanisms and send it to jsp-spec-comments@eng? I get
> requests about this now and then but it never seems to get over the cut
> line.
>
> - eduard/o
>
> "Craig R. McClanahan" wrote:
>
> > I will think about this as I'm adding full support for indexed property
> > getters/setters (based on input from several people on the
> STRUTS-DEV list).
> >
> > Craig
>
Re: Override auto-population feature of Struts (repost)?
Posted by Eduardo Pelegri--Llopart <Ed...@eng.sun.com>.
If the struts community feels the need for this, perhaps somebody could
compose a proposal for exntending the base jsp:setProperty and
jsp:getProperty mechanisms and send it to jsp-spec-comments@eng? I get
requests about this now and then but it never seems to get over the cut
line.
- eduard/o
"Craig R. McClanahan" wrote:
> I will think about this as I'm adding full support for indexed property
> getters/setters (based on input from several people on the STRUTS-DEV list).
>
> Craig
Re: Override auto-population feature of Struts (repost)?
Posted by Daniel Abrams <ma...@masslight.com>.
In the OpenStep/WebObjects world we call this key-value coding and it is
central to most of the autopopulation that goes on in these environments,
whether from form to bean or bean to database. your
"store.seller.firstName" is what we call a keyPath (as opposed to a key
which is just "store"), and is basically traversed like you suggest. We
begin with a root object, in a number of ways, and start traversing the
keypath. That is, if we had a store object, the key-value coding would look
first for a seller() or getSeller() accessor, and if it didnt find one,
would look for the instance variable, all via reflection, next to firstName,
and so on.
Accessing things in this way is _phenomenally_ useful. You can easily
"bind" these keyPaths to attributes in all sorts of interesting ways. You
can have your object graph automatically populated whenever users submit
pages, without having to do any coding. It is something I am really
missing.
Daniel Abrams
MassLight
>
> <input type="text" name="Seller.FirstName" value="<%=
> bean.getSeller().getFirstName() %>">
>
> and his code he wrote will parse the "." in the name of the element and
call
> the Buyer.getSeller().setFirstName() method. Thus, you can set forms to
use
> specific objects in the main object...nested object property population
> basically.
>
> So what do you think? On one hand..it isn't as pretty for web page
> developers, but on the other hand, it allows specific direction in objects
> for the population code. Anyways..he said he would be willing to give the
> code to you..although I am pretty sure you guys could whip it up quite
> easily.
>
> So I would ask that the Struts community and development team give some
> consideration to somehow allowing a nesting population mechanism. One that
> would allow the use of model or business beans to be populated via Struts
> that are not dependant on Struts, and would also allow this nested
> population mechanism, which will allow specific tailoring of forms to
> populate nested objects in a bean. Again, this last one is not beautiful
for
> solid web-html content developers, but it is relatively easy for a
front-end
> developer to tell the web-content guy/gal to use specific names in the
form
> elements, but allow them to do their magic with the layout, etc.
>
> So..how does this "proposal" go into motion as far as seeing it introduced
> into struts? Should I and my co-worker take the source of Struts, work the
> population code a bit so that it can do this, then send it back? Or is
this
> not an open source community project yet?
>
> Thanks. Look forward to contributing.
>
Re: Override auto-population feature of Struts (repost)?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> [snip]
> Another thing..the way this should work is that we have a JavaBean used by a
> JSP page but this javabean doesn't have any getter/setter methods in it that
> the MODEL bean already has. The reflection code would simply look at every
> request.getParameter() in the request, and call upon the Buyer classes
> setter methods of the same name..if they exist. Some code would be in place
> to make sure the method exists in the Buyer class.
>
If all you want is to copy request parameters to bean properties, you've got
everything you need already (because that is how Struts populates the form
bean):
... assume "request" is the HttpServletRequest ...
Buyer myBuyer = new Buyer (... whatever ...);
BeanUtils.populate(myBuyer, request);
The new code discussed earlier would be to copy like-named properties from one
bean to another (which presumes that you are using ActionForm beans the way they
were intended).
>
> On an interesting note, one of our engineers here wrote some reflection code
> last night that does something I never though of. It populats a class
> including objects in the class (and their setter methods), based on the form
> element names. Not sure how to explain this, but as he calls it, nested
> reflection. You have a form like so:
>
> <input type="text" name="Seller.FirstName" value="<%=
> bean.getSeller().getFirstName() %>">
>
> and his code he wrote will parse the "." in the name of the element and call
> the Buyer.getSeller().setFirstName() method. Thus, you can set forms to use
> specific objects in the main object...nested object property population
> basically.
Nested getters and setters would be interesting, and might be something useful
in JSP itself (it's similar in some respects to the way that JavaScript lets you
access nested properties. I would be interested in seeing the code -- although
it might end up getting melded into the overall framework differently than the
way you guys built it for your specific needs.
Craig
Re: Override auto-population feature of Struts (repost)?
Posted by Rod McChesney <ro...@expressaction.com>.
If you call setters on your database-mapped object directly, and there's
an error in the data, you have kind of a mess on your hands. You need
to keep the original data around to show the user what went wrong, but
you don't want it to get into the database, or even into an in-memory
version of the database. I believe it's usually better to have one object
for the form fields (which may or may not map 1:1 with the database
object) and separate database objects. You could then do automatic
property matching if you wanted, but I think you'll find that keeping
the objects separate is the right design choice going forward.
OTOH, foo.bar.baz style properties are tremendously useful, and are
present in WebMacro and possible other template systems. But this is a
different thing than mapping straight to business objects, I think.
Or am I misunderstanding what you're asking for?
Rod McChesney
Kevin Duffey wrote:
>
> Hi,
>
> > In other words, you want to be able to auto-magically "copy" all
> > the matching
> > properties from one bean (the ActionForm bean) to your business
> > object bean
> > (Buyer, Seller, etc.) without having to write all the setXxxxx
> > calls, right?
> > Boy, some people are *never* satisfied ... :-) :-)
>
> Hahah..but in actuality, this seems like it would be a pretty common thing.
> I should say, our Buyer class, for example, is a model of the database
> table, so when you say business logic classes, I don't know if that is the
> same thing. Basically, we have a "store" method in our Buyer class that
> passes a Buyer.class to our persistence method that stores an entire buyer
> in the buyer table. I don't know exactly how this works, I haven't worked on
> this code. But, I think that a Buyer class is more the entity bean (although
> not in the EJB aspect)..its like a 1 to 1 relation to the table in the
> database.
>
> Another thing..the way this should work is that we have a JavaBean used by a
> JSP page but this javabean doesn't have any getter/setter methods in it that
> the MODEL bean already has. The reflection code would simply look at every
> request.getParameter() in the request, and call upon the Buyer classes
> setter methods of the same name..if they exist. Some code would be in place
> to make sure the method exists in the Buyer class.
>
> On an interesting note, one of our engineers here wrote some reflection code
> last night that does something I never though of. It populats a class
> including objects in the class (and their setter methods), based on the form
> element names. Not sure how to explain this, but as he calls it, nested
> reflection. You have a form like so:
>
> <input type="text" name="Seller.FirstName" value="<%=
> bean.getSeller().getFirstName() %>">
>
> and his code he wrote will parse the "." in the name of the element and call
> the Buyer.getSeller().setFirstName() method. Thus, you can set forms to use
> specific objects in the main object...nested object property population
> basically.
>
> So what do you think? On one hand..it isn't as pretty for web page
> developers, but on the other hand, it allows specific direction in objects
> for the population code. Anyways..he said he would be willing to give the
> code to you..although I am pretty sure you guys could whip it up quite
> easily.
>
> So I would ask that the Struts community and development team give some
> consideration to somehow allowing a nesting population mechanism. One that
> would allow the use of model or business beans to be populated via Struts
> that are not dependant on Struts, and would also allow this nested
> population mechanism, which will allow specific tailoring of forms to
> populate nested objects in a bean. Again, this last one is not beautiful for
> solid web-html content developers, but it is relatively easy for a front-end
> developer to tell the web-content guy/gal to use specific names in the form
> elements, but allow them to do their magic with the layout, etc.
>
> So..how does this "proposal" go into motion as far as seeing it introduced
> into struts? Should I and my co-worker take the source of Struts, work the
> population code a bit so that it can do this, then send it back? Or is this
> not an open source community project yet?
>
> Thanks. Look forward to contributing.
RE: Override auto-population feature of Struts (repost)?
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> In other words, you want to be able to auto-magically "copy" all
> the matching
> properties from one bean (the ActionForm bean) to your business
> object bean
> (Buyer, Seller, etc.) without having to write all the setXxxxx
> calls, right?
> Boy, some people are *never* satisfied ... :-) :-)
Hahah..but in actuality, this seems like it would be a pretty common thing.
I should say, our Buyer class, for example, is a model of the database
table, so when you say business logic classes, I don't know if that is the
same thing. Basically, we have a "store" method in our Buyer class that
passes a Buyer.class to our persistence method that stores an entire buyer
in the buyer table. I don't know exactly how this works, I haven't worked on
this code. But, I think that a Buyer class is more the entity bean (although
not in the EJB aspect)..its like a 1 to 1 relation to the table in the
database.
Another thing..the way this should work is that we have a JavaBean used by a
JSP page but this javabean doesn't have any getter/setter methods in it that
the MODEL bean already has. The reflection code would simply look at every
request.getParameter() in the request, and call upon the Buyer classes
setter methods of the same name..if they exist. Some code would be in place
to make sure the method exists in the Buyer class.
On an interesting note, one of our engineers here wrote some reflection code
last night that does something I never though of. It populats a class
including objects in the class (and their setter methods), based on the form
element names. Not sure how to explain this, but as he calls it, nested
reflection. You have a form like so:
<input type="text" name="Seller.FirstName" value="<%=
bean.getSeller().getFirstName() %>">
and his code he wrote will parse the "." in the name of the element and call
the Buyer.getSeller().setFirstName() method. Thus, you can set forms to use
specific objects in the main object...nested object property population
basically.
So what do you think? On one hand..it isn't as pretty for web page
developers, but on the other hand, it allows specific direction in objects
for the population code. Anyways..he said he would be willing to give the
code to you..although I am pretty sure you guys could whip it up quite
easily.
So I would ask that the Struts community and development team give some
consideration to somehow allowing a nesting population mechanism. One that
would allow the use of model or business beans to be populated via Struts
that are not dependant on Struts, and would also allow this nested
population mechanism, which will allow specific tailoring of forms to
populate nested objects in a bean. Again, this last one is not beautiful for
solid web-html content developers, but it is relatively easy for a front-end
developer to tell the web-content guy/gal to use specific names in the form
elements, but allow them to do their magic with the layout, etc.
So..how does this "proposal" go into motion as far as seeing it introduced
into struts? Should I and my co-worker take the source of Struts, work the
population code a bit so that it can do this, then send it back? Or is this
not an open source community project yet?
Thanks. Look forward to contributing.
Re: Override auto-population feature of Struts (repost)?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> The reason is, we have "core" classes that are to be repackaged (we are
> restructuring our code base) into a single JAR file that will NOT be
> dependant on struts. Thus, a Buyer class can not implement the ActionForm
> interface.
>
> What we wanted was a DefaultBean that implements ActionForm. It also
> implements a few methods that all our front-end javabeans will need to use.
> But, our core classes, Buyer, Seller, Station, User, Enrollee, etc..will be
> part of the core package that is to be distributed to other developers as
> well. Therefore, we want our front-end bean to be able to be auto-populated
> by Struts but have it auto-populate a Buyer object, User object, etc
> depending on the bean.
In other words, you want to be able to auto-magically "copy" all the matching
properties from one bean (the ActionForm bean) to your business object bean
(Buyer, Seller, etc.) without having to write all the setXxxxx calls, right?
Boy, some people are *never* satisfied ... :-) :-)
In principle, it seems feasible to create something similar to
BeanUtils.populate() that used Java reflection on both the source and the
destination beans to do something like this. It would locate all the property
getters on the source bean, and call the corresponding property setters on the
destination bean if the property names matched. Because the BeanUtils methods
deal with Objects (not ActionForms), your goal of non-Struts-dependency in the
business logic classes (a good idea, by the way) can also be achieved.
Note that there will be a performance (CPU time) impact of doing this, versus
hand coding the setXxxx methods, but it is probably not a huge impact. Besides,
CPU power is one of the easiest things to add to your production servers if you
need more of it.
I will think about this as I'm adding full support for indexed property
getters/setters (based on input from several people on the STRUTS-DEV list).
Craig
RE: Override auto-population feature of Struts (repost)?
Posted by Kevin Duffey <kd...@buymedia.com>.
The reason is, we have "core" classes that are to be repackaged (we are
restructuring our code base) into a single JAR file that will NOT be
dependant on struts. Thus, a Buyer class can not implement the ActionForm
interface.
What we wanted was a DefaultBean that implements ActionForm. It also
implements a few methods that all our front-end javabeans will need to use.
But, our core classes, Buyer, Seller, Station, User, Enrollee, etc..will be
part of the core package that is to be distributed to other developers as
well. Therefore, we want our front-end bean to be able to be auto-populated
by Struts but have it auto-populate a Buyer object, User object, etc
depending on the bean. Its what we would call, nested auto-population. It
would be nice if there was a way that Struts automatically looked for an
"entity" Object type in the ActionForm implemented javabean, and also took
on a class that represents the type of object the entity field would
represent. This way, each javabean can dynamically choose a different class
that the entity field represents. Then I would not need to typecast.
Ideally, we want to eliminate any getter/setter method calls in our
front-end beans and have Struts call the getter/setter methods of the
underlying "core" class. I know there has got to be a way to do this. One of
our engineers decided to write his own version of auto-population and I am
hoping to avoid having to use it..because I am pretty sure it will screw up
our ability to use Struts. The main reason it would screw things up is that
in the action.xml file, I would not be able to use form classes any longer,
as there wouldn't be any reason for Struts to auto-populate our bean if it
can't populate the underlying object the bean represents..which WONT
implement ActionForm. I hope I am a bit clearer on this.
> Why not declaring your entity variable of type "Buyer" instead of Object ?
> Additionally if performance is an issue declare the methods to be
> final. And
> is auto-population not done for "ActionForm" classes ?
>
> Beside this I think the Buyer class is one object of your business layer
> classes and should definitely not inherit from Action or ActionForm but
> should be called from an Action class.
>
> The perform Method of your Action class should check the values within the
> ActionForm class (that should have some Methods like your Buyer class) and
> pass them (if correct) to the Buyer object.
This last paragraph is basically what we want to do. However, I am hoping in
my action class that I don't have to call every setter method of my Buyer
object, for example, with a bunch of request.getParameter() fields. Recall
that in my ActionForm bean I want to eliminate the need to code the SAME
getter/setter methods that my Buyer class already does. Basically, I am
doing double work. Again..because Buyer and other "core" classes will be
packaged in a .jar file and distributed, we can't be dependent on ActionForm
and struts. So, there would need to be some mechanism in place that I could
tell Struts..this bean requires auto-population, but call the "entity"
object's setter methods directly, instead of this beans setter methods. This
way, I don't have a getFirstName() and setFirstName() method in my bean,
which basically calls upon the Buyer getFirstName() and setFirstName(). I am
repeating code in my javabeans, and I am hoping to avoid that somehow.
Any suggestion as to how this can be done, including if the Struts team
could put something in place to allow this to work. I can't imagine I am the
only one that has "core" classes that can not rely on Struts, but want to
use the auto-population feature so that front-end beans can take on the
basic behavior of core classes, but not have to redo all the getter/setter
methods that are already coded in the core class.
Thanks.
RE: Override auto-population feature of Struts (repost)?
Posted by Stefan Wesner <we...@rus.uni-stuttgart.de>.
Hi,
why are you using in your example listing typecasting at all ?
Why not declaring your entity variable of type "Buyer" instead of Object ?
Additionally if performance is an issue declare the methods to be final. And
is auto-population not done for "ActionForm" classes ?
Beside this I think the Buyer class is one object of your business layer
classes and should definitely not inherit from Action or ActionForm but
should be called from an Action class.
The perform Method of your Action class should check the values within the
ActionForm class (that should have some Methods like your Buyer class) and
pass them (if correct) to the Buyer object.
Hope this helps,
Stefan Wesner.
> Hi,
>
> I am wondering if its possible to override or extend the part of
> Struts that
> handles (or is called) auto-population of beans from form
> elements. We have
> a "foundation" of classes that are basically beans, and it would be
> wonderful if we could not have to create many get/set methods in
> beans that
> basically typecast an "entity" object field in each bean to the specific
> type of object the bean will model. For example, we have
> something like so:
>
> public class Buyer
> {
> private String firstName = "";
> private String lastName = "";
>
> public Buyer()
> {
> }
>
> public String getFirstName()
> {
> return firstName;
> }
>
> public String getLastName()
> {
> return lastName;
> }
>
> public void setFirstName(String value)
> {
> firstName = value;
> }
>
> public void setLastName(String value)
> {
> lastName = value;
> }
> }
>
>
> This is part of our core package that many of our web apps use. However,
> these are core classes that will not implement the Action
> interface (thus be
> dependont on struts.jar to work). Instead, I am wondering if there is some
> way to get the auot-population feature to just use the "core" beans and
> populate their fields directly, without having to do the following:
>
> public class SomeBean
> implements Action
> {
> private Object entity = null;
>
> public SomeBean()
> {
> entity = new Buyer();
> }
>
> public String getFirstName()
> {
> return ( (Buyer) entity).getFirstName();
> }
>
> public String getLastName()
> {
> return ( (Buyer) entity).getLastName();
> }
>
> public void setFirstName(String value)
> {
> ( (Buyer) entity).setFirstName(value);
> }
>
> public void setLastName(String value)
> {
> ( (Buyer) entity).setLastName(value);
> }
> }
>
>
> While I don't see a big deal with the approach I have taken, I am not sure
> if the type-casting slows things down, and if it would be faster just to
> directly populate a Buyer object. Is there a reason the bean must
> implement
> the Action interface?
>
> Thanks.
>
>