You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dan Jacobs <dj...@modelobjects.com> on 2003/06/24 14:21:38 UTC
Object-oriented encapsulation in Struts - merging Actions and ActionForms
[ potentially controversial topic ]
Hi all,
I have noticed that most of my Struts applications end up being
implemented like dismembered objects.
I design the controller parts of my Struts applications using
object-oriented design techniques, but then I have to transform my
designs into an awkward, non-object-oriented form:
* What was originally encapsulated object state has to be extracted
and isolated as ActionForms.
* What were originally methods that acted on encapsulated object state
have to become stateless processors in the form of Actions.
* The Struts servlet acts like another method-turned-C-function when
it resets and assigns property-values in the ActionForms.
I can translate in the other direction too. If I take someone else's
Struts application, I can derive an effective object model from the
relationships between the Actions and ActionForms described in the
struts-config.xml file. That's really useful for figuring out what's
going on.
There's no problem getting all of this to work, and the Struts servlet
and framework do some very useful things. But the separation of the
Actions from the ActionForms makes it harder to maintain the integrity
of the original object-oriented designs.
What I'd really like to see is a truly object-oriented approach to the
controller, where the state of the web-application is encapsulated as
instances of real classes (not just the equivalent of C struts) that
are acted on by methods. The methods would be invoked just like
Actions are currently invoked, but rather than pass behavior-less data
to data-less functions, we could have methods acting on encapsulated
object state. Who knows - maybe someday we could even have subclasses
and inheritance and constructors and methods with method parameters.
If action-mappings could map to methods invoked on named instances,
Actions and ActionForms could be merged into real objects, and the
object-oriented character of controller designs could be maintained.
Is there any compelling reason that this shouldn't be done?
I can get the object-oriented behavior I want using JPlates, but I
don't want to have to duplicate all of the other contributions that
Struts offers for web-applications. I use JPlates with Struts, but
I'd be happier with a more object-oriented version of Struts.
Dan Jacobs
JPlates Inc.
http://www.jplates.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Dan Jacobs" <dj...@modelobjects.com>
To: <dg...@apache.org>; "'Struts Users Mailing List'"
<st...@jakarta.apache.org>
Sent: Tuesday, June 24, 2003 10:39 AM
Subject: RE: Object-oriented encapsulation in Struts - merging Actions and
ActionForms
> The kind of change I'm suggesting is not small or incremental. It's
> pretty fundamental.
>
> Suppose you've got an ActionForm that represents the state of some
> presentation object. It has no object-oriented behavior at all. Just
> ways to read and write its fields.
The designed behaviors of form beans (instances of ActionForm)
are the same as data buffers on web forms.
>
> Now suppose you've got some Actions that are meant to do things based on
> the ActionForm. They're like "C" functions in that they just compute,
> and are not associated with any instance data. They can access the
> equivalent of global data from the session, but they're not really
> methods of objects.
The designed behaviors of actions are to operate the data buffers with
environment data.
>
> Now combine them. Define a class where the instance state is basically
> the same as what was in the ActionForm, and that defines methods that do
> the same things as were done by the Actions. But instead of passing an
> ActionForm to an Action, just invoke a method on an object.
There is nothing in the action classes that prevents you from creating
your faviorable objects in your faviorable MVC patterns with your
faviorable methods. The hard question is that how can I describe this
idea as a *fundamental* advance to the Struts framework?
Thanks Craig for giving us so much room to innovate within
the framework.
>
> The rest of the implementation is a matter of reflection tricks, and
> there probably has to be some additional framework support to compensate
> for the lack of closures in Java, and make the methods act like objects
> that conform to some required interface.
>
> Does that make sense?
>
> Dan Jacobs
> JPlates Inc.
> http://www.jplates.com
Jing
>
> > -----Original Message-----
> > From: David Graham [mailto:grahamdavid1980@yahoo.com]
> > Sent: Tuesday, June 24, 2003 8:46 AM
> > To: Struts Users Mailing List
> > Subject: Re: Object-oriented encapsulation in Struts -
> > merging Actions and ActionForms
> >
> >
> > Specifically, what would you change?
> >
> > David
> >
> > --- Dan Jacobs <dj...@modelobjects.com> wrote:
> > > [ potentially controversial topic ]
> > > Hi all,
> > > I have noticed that most of my Struts applications
> > > end up being
> > > implemented like dismembered objects.
> > >
> > > I design the controller parts of my Struts
> > > applications using
> > > object-oriented design techniques, but then I have
> > > to transform my
> > > designs into an awkward, non-object-oriented form:
> > >
> > > * What was originally encapsulated object state has
> > > to be extracted
> > > and isolated as ActionForms.
> > >
> > > * What were originally methods that acted on
> > > encapsulated object state
> > > have to become stateless processors in the form of
> > > Actions.
> > >
> > > * The Struts servlet acts like another method-turned-C-function when
> > > it resets and assigns property-values in the
> > > ActionForms.
> > >
> > > I can translate in the other direction too. If I
> > > take someone else's
> > > Struts application, I can derive an effective object
> > > model from the
> > > relationships between the Actions and ActionForms
> > > described in the
> > > struts-config.xml file. That's really useful for
> > > figuring out what's
> > > going on.
> > >
> > > There's no problem getting all of this to work, and
> > > the Struts servlet
> > > and framework do some very useful things. But the
> > > separation of the
> > > Actions from the ActionForms makes it harder to
> > > maintain the integrity
> > > of the original object-oriented designs.
> > >
> > > What I'd really like to see is a truly
> > > object-oriented approach to the
> > > controller, where the state of the web-application
> > > is encapsulated as
> > > instances of real classes (not just the equivalent
> > > of C struts) that
> > > are acted on by methods. The methods would be
> > > invoked just like
> > > Actions are currently invoked, but rather than pass
> > behavior-less data
> > > to data-less functions, we could have methods acting
> > > on encapsulated
> > > object state. Who knows - maybe someday we could
> > > even have subclasses
> > > and inheritance and constructors and methods with
> > > method parameters.
> > >
> > > If action-mappings could map to methods invoked on
> > > named instances,
> > > Actions and ActionForms could be merged into real
> > > objects, and the
> > > object-oriented character of controller designs
> > > could be maintained.
> > >
> > > Is there any compelling reason that this shouldn't
> > > be done?
> > >
> > >
> > > I can get the object-oriented behavior I want using
> > > JPlates, but I
> > > don't want to have to duplicate all of the other contributions that
> > > Struts offers for web-applications. I use JPlates
> > > with Struts, but
> > > I'd be happier with a more object-oriented version
> > > of Struts.
> > >
> > > Dan Jacobs
> > > JPlates Inc.
> > > http://www.jplates.com
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Posted by Dan Jacobs <dj...@modelobjects.com>.
It's perfectly reasonable to have classes that don't have instance
variables, though in most cases they're of limited utility. An Action
without an ActionForm would correspond to such a class.
Dan Jacobs
JPlates Inc.
http://www.jplates.com
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: Tuesday, June 24, 2003 11:06 AM
> To: struts-user@jakarta.apache.org
> Subject: RE: Object-oriented encapsulation in Struts -
> merging Actions and ActionForms
>
>
> So you want to combine ActionForm and Action to put the
> behavior with the data? How would you handle the case where
> Actions are responding to requests without an associated ActionForm?
>
> It's true that ActionForm and Action break encapsulation but
> this may be an acceptable tradeoff. Thanks for bringing this
> up; I'll think about it some more and get back to you.
>
> David
>
> --- Dan Jacobs <dj...@modelobjects.com> wrote:
> > The kind of change I'm suggesting is not small or
> incremental. It's
> > pretty fundamental.
> >
> > Suppose you've got an ActionForm that represents the state of some
> > presentation object. It has no object-oriented behavior at
> all. Just
> > ways to read and write its fields.
> >
> > Now suppose you've got some Actions that are meant to do
> things based
> > on the ActionForm. They're like "C" functions in that they just
> > compute, and are not associated with any instance data. They can
> > access the equivalent of global data from the session, but
> they're not
> > really methods of objects.
> >
> > Now combine them. Define a class where the instance state is
> > basically the same as what was in the ActionForm, and that defines
> > methods that do the same things as were done by the Actions. But
> > instead of passing an ActionForm to an Action, just invoke
> a method on
> > an object.
> >
> > The rest of the implementation is a matter of reflection
> tricks, and
> > there probably has to be some additional framework support to
> > compensate for the lack of closures in Java, and make the
> methods act
> > like objects that conform to some required interface.
> >
> > Does that make sense?
> >
> > Dan Jacobs
> > JPlates Inc.
> > http://www.jplates.com
> >
> > > -----Original Message-----
> > > From: David Graham [mailto:grahamdavid1980@yahoo.com]
> > > Sent: Tuesday, June 24, 2003 8:46 AM
> > > To: Struts Users Mailing List
> > > Subject: Re: Object-oriented encapsulation in Struts -
> > > merging Actions and ActionForms
> > >
> > >
> > > Specifically, what would you change?
> > >
> > > David
> > >
> > > --- Dan Jacobs <dj...@modelobjects.com> wrote:
> > > > [ potentially controversial topic ]
> > > > Hi all,
> > > > I have noticed that most of my Struts applications
> > > > end up being
> > > > implemented like dismembered objects.
> > > >
> > > > I design the controller parts of my Struts
> > > > applications using
> > > > object-oriented design techniques, but then I have
> > > > to transform my
> > > > designs into an awkward, non-object-oriented form:
> > > >
> > > > * What was originally encapsulated object state has
> > > > to be extracted
> > > > and isolated as ActionForms.
> > > >
> > > > * What were originally methods that acted on
> > > > encapsulated object state
> > > > have to become stateless processors in the form of Actions.
> > > >
> > > > * The Struts servlet acts like another
> method-turned-C-function when
> > > > it resets and assigns property-values in the ActionForms.
> > > >
> > > > I can translate in the other direction too. If I
> > > > take someone else's
> > > > Struts application, I can derive an effective object model from
> > > > the relationships between the Actions and ActionForms
> > > > described in the
> > > > struts-config.xml file. That's really useful for
> > > > figuring out what's
> > > > going on.
> > > >
> > > > There's no problem getting all of this to work, and
> > > > the Struts servlet
> > > > and framework do some very useful things. But the
> separation of
> > > > the Actions from the ActionForms makes it harder to
> > > > maintain the integrity
> > > > of the original object-oriented designs.
> > > >
> > > > What I'd really like to see is a truly
> > > > object-oriented approach to the
> > > > controller, where the state of the web-application
> > > > is encapsulated as
> > > > instances of real classes (not just the equivalent
> > > > of C struts) that
> > > > are acted on by methods. The methods would be
> > > > invoked just like
> > > > Actions are currently invoked, but rather than pass
> > > behavior-less data
> > > > to data-less functions, we could have methods acting
> > > > on encapsulated
> > > > object state. Who knows - maybe someday we could
> > > > even have subclasses
> > > > and inheritance and constructors and methods with
> > > > method parameters.
> > > >
> > > > If action-mappings could map to methods invoked on
> > > > named instances,
> > > > Actions and ActionForms could be merged into real
> objects, and the
> > > > object-oriented character of controller designs
> > > > could be maintained.
> > > >
> > > > Is there any compelling reason that this shouldn't
> > > > be done?
> > > >
> > > >
> > > > I can get the object-oriented behavior I want using
> JPlates, but I
> > > > don't want to have to duplicate all of the other
> contributions that
> > > > Struts offers for web-applications. I use JPlates
> > > > with Struts, but
> > > > I'd be happier with a more object-oriented version
> > > > of Struts.
> > > >
> > > > Dan Jacobs
> > > > JPlates Inc.
> > > > http://www.jplates.com
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > > struts-user-help@jakarta.apache.org
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> > >
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Posted by David Graham <gr...@yahoo.com>.
So you want to combine ActionForm and Action to put the behavior with the
data? How would you handle the case where Actions are responding to
requests without an associated ActionForm?
It's true that ActionForm and Action break encapsulation but this may be
an acceptable tradeoff. Thanks for bringing this up; I'll think about it
some more and get back to you.
David
--- Dan Jacobs <dj...@modelobjects.com> wrote:
> The kind of change I'm suggesting is not small or incremental. It's
> pretty fundamental.
>
> Suppose you've got an ActionForm that represents the state of some
> presentation object. It has no object-oriented behavior at all. Just
> ways to read and write its fields.
>
> Now suppose you've got some Actions that are meant to do things based on
> the ActionForm. They're like "C" functions in that they just compute,
> and are not associated with any instance data. They can access the
> equivalent of global data from the session, but they're not really
> methods of objects.
>
> Now combine them. Define a class where the instance state is basically
> the same as what was in the ActionForm, and that defines methods that do
> the same things as were done by the Actions. But instead of passing an
> ActionForm to an Action, just invoke a method on an object.
>
> The rest of the implementation is a matter of reflection tricks, and
> there probably has to be some additional framework support to compensate
> for the lack of closures in Java, and make the methods act like objects
> that conform to some required interface.
>
> Does that make sense?
>
> Dan Jacobs
> JPlates Inc.
> http://www.jplates.com
>
> > -----Original Message-----
> > From: David Graham [mailto:grahamdavid1980@yahoo.com]
> > Sent: Tuesday, June 24, 2003 8:46 AM
> > To: Struts Users Mailing List
> > Subject: Re: Object-oriented encapsulation in Struts -
> > merging Actions and ActionForms
> >
> >
> > Specifically, what would you change?
> >
> > David
> >
> > --- Dan Jacobs <dj...@modelobjects.com> wrote:
> > > [ potentially controversial topic ]
> > > Hi all,
> > > I have noticed that most of my Struts applications
> > > end up being
> > > implemented like dismembered objects.
> > >
> > > I design the controller parts of my Struts
> > > applications using
> > > object-oriented design techniques, but then I have
> > > to transform my
> > > designs into an awkward, non-object-oriented form:
> > >
> > > * What was originally encapsulated object state has
> > > to be extracted
> > > and isolated as ActionForms.
> > >
> > > * What were originally methods that acted on
> > > encapsulated object state
> > > have to become stateless processors in the form of
> > > Actions.
> > >
> > > * The Struts servlet acts like another method-turned-C-function when
> > > it resets and assigns property-values in the
> > > ActionForms.
> > >
> > > I can translate in the other direction too. If I
> > > take someone else's
> > > Struts application, I can derive an effective object
> > > model from the
> > > relationships between the Actions and ActionForms
> > > described in the
> > > struts-config.xml file. That's really useful for
> > > figuring out what's
> > > going on.
> > >
> > > There's no problem getting all of this to work, and
> > > the Struts servlet
> > > and framework do some very useful things. But the
> > > separation of the
> > > Actions from the ActionForms makes it harder to
> > > maintain the integrity
> > > of the original object-oriented designs.
> > >
> > > What I'd really like to see is a truly
> > > object-oriented approach to the
> > > controller, where the state of the web-application
> > > is encapsulated as
> > > instances of real classes (not just the equivalent
> > > of C struts) that
> > > are acted on by methods. The methods would be
> > > invoked just like
> > > Actions are currently invoked, but rather than pass
> > behavior-less data
> > > to data-less functions, we could have methods acting
> > > on encapsulated
> > > object state. Who knows - maybe someday we could
> > > even have subclasses
> > > and inheritance and constructors and methods with
> > > method parameters.
> > >
> > > If action-mappings could map to methods invoked on
> > > named instances,
> > > Actions and ActionForms could be merged into real
> > > objects, and the
> > > object-oriented character of controller designs
> > > could be maintained.
> > >
> > > Is there any compelling reason that this shouldn't
> > > be done?
> > >
> > >
> > > I can get the object-oriented behavior I want using
> > > JPlates, but I
> > > don't want to have to duplicate all of the other contributions that
> > > Struts offers for web-applications. I use JPlates
> > > with Struts, but
> > > I'd be happier with a more object-oriented version
> > > of Struts.
> > >
> > > Dan Jacobs
> > > JPlates Inc.
> > > http://www.jplates.com
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> >
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Posted by Dan Jacobs <dj...@modelobjects.com>.
The kind of change I'm suggesting is not small or incremental. It's
pretty fundamental.
Suppose you've got an ActionForm that represents the state of some
presentation object. It has no object-oriented behavior at all. Just
ways to read and write its fields.
Now suppose you've got some Actions that are meant to do things based on
the ActionForm. They're like "C" functions in that they just compute,
and are not associated with any instance data. They can access the
equivalent of global data from the session, but they're not really
methods of objects.
Now combine them. Define a class where the instance state is basically
the same as what was in the ActionForm, and that defines methods that do
the same things as were done by the Actions. But instead of passing an
ActionForm to an Action, just invoke a method on an object.
The rest of the implementation is a matter of reflection tricks, and
there probably has to be some additional framework support to compensate
for the lack of closures in Java, and make the methods act like objects
that conform to some required interface.
Does that make sense?
Dan Jacobs
JPlates Inc.
http://www.jplates.com
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: Tuesday, June 24, 2003 8:46 AM
> To: Struts Users Mailing List
> Subject: Re: Object-oriented encapsulation in Struts -
> merging Actions and ActionForms
>
>
> Specifically, what would you change?
>
> David
>
> --- Dan Jacobs <dj...@modelobjects.com> wrote:
> > [ potentially controversial topic ]
> > Hi all,
> > I have noticed that most of my Struts applications
> > end up being
> > implemented like dismembered objects.
> >
> > I design the controller parts of my Struts
> > applications using
> > object-oriented design techniques, but then I have
> > to transform my
> > designs into an awkward, non-object-oriented form:
> >
> > * What was originally encapsulated object state has
> > to be extracted
> > and isolated as ActionForms.
> >
> > * What were originally methods that acted on
> > encapsulated object state
> > have to become stateless processors in the form of
> > Actions.
> >
> > * The Struts servlet acts like another method-turned-C-function when
> > it resets and assigns property-values in the
> > ActionForms.
> >
> > I can translate in the other direction too. If I
> > take someone else's
> > Struts application, I can derive an effective object
> > model from the
> > relationships between the Actions and ActionForms
> > described in the
> > struts-config.xml file. That's really useful for
> > figuring out what's
> > going on.
> >
> > There's no problem getting all of this to work, and
> > the Struts servlet
> > and framework do some very useful things. But the
> > separation of the
> > Actions from the ActionForms makes it harder to
> > maintain the integrity
> > of the original object-oriented designs.
> >
> > What I'd really like to see is a truly
> > object-oriented approach to the
> > controller, where the state of the web-application
> > is encapsulated as
> > instances of real classes (not just the equivalent
> > of C struts) that
> > are acted on by methods. The methods would be
> > invoked just like
> > Actions are currently invoked, but rather than pass
> behavior-less data
> > to data-less functions, we could have methods acting
> > on encapsulated
> > object state. Who knows - maybe someday we could
> > even have subclasses
> > and inheritance and constructors and methods with
> > method parameters.
> >
> > If action-mappings could map to methods invoked on
> > named instances,
> > Actions and ActionForms could be merged into real
> > objects, and the
> > object-oriented character of controller designs
> > could be maintained.
> >
> > Is there any compelling reason that this shouldn't
> > be done?
> >
> >
> > I can get the object-oriented behavior I want using
> > JPlates, but I
> > don't want to have to duplicate all of the other contributions that
> > Struts offers for web-applications. I use JPlates
> > with Struts, but
> > I'd be happier with a more object-oriented version
> > of Struts.
> >
> > Dan Jacobs
> > JPlates Inc.
> > http://www.jplates.com
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Posted by David Graham <gr...@yahoo.com>.
Specifically, what would you change?
David
--- Dan Jacobs <dj...@modelobjects.com> wrote:
> [ potentially controversial topic ]
> Hi all,
> I have noticed that most of my Struts applications
> end up being
> implemented like dismembered objects.
>
> I design the controller parts of my Struts
> applications using
> object-oriented design techniques, but then I have
> to transform my
> designs into an awkward, non-object-oriented form:
>
> * What was originally encapsulated object state has
> to be extracted
> and isolated as ActionForms.
>
> * What were originally methods that acted on
> encapsulated object state
> have to become stateless processors in the form of
> Actions.
>
> * The Struts servlet acts like another
> method-turned-C-function when
> it resets and assigns property-values in the
> ActionForms.
>
> I can translate in the other direction too. If I
> take someone else's
> Struts application, I can derive an effective object
> model from the
> relationships between the Actions and ActionForms
> described in the
> struts-config.xml file. That's really useful for
> figuring out what's
> going on.
>
> There's no problem getting all of this to work, and
> the Struts servlet
> and framework do some very useful things. But the
> separation of the
> Actions from the ActionForms makes it harder to
> maintain the integrity
> of the original object-oriented designs.
>
> What I'd really like to see is a truly
> object-oriented approach to the
> controller, where the state of the web-application
> is encapsulated as
> instances of real classes (not just the equivalent
> of C struts) that
> are acted on by methods. The methods would be
> invoked just like
> Actions are currently invoked, but rather than pass
> behavior-less data
> to data-less functions, we could have methods acting
> on encapsulated
> object state. Who knows - maybe someday we could
> even have subclasses
> and inheritance and constructors and methods with
> method parameters.
>
> If action-mappings could map to methods invoked on
> named instances,
> Actions and ActionForms could be merged into real
> objects, and the
> object-oriented character of controller designs
> could be maintained.
>
> Is there any compelling reason that this shouldn't
> be done?
>
>
> I can get the object-oriented behavior I want using
> JPlates, but I
> don't want to have to duplicate all of the other
> contributions that
> Struts offers for web-applications. I use JPlates
> with Struts, but
> I'd be happier with a more object-oriented version
> of Struts.
>
> Dan Jacobs
> JPlates Inc.
> http://www.jplates.com
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org