You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Jones, Ted" <Te...@maritz.com> on 2003/06/24 17:50:12 UTC
RE: Object-oriented encapsulation in Struts - merging Actions and
ActionForms
That makes sense ...but wouldn't that break the MVC pattern by moving
the Controller function into the Model?
Ted Jones
Maritz Inc.
ted.jones@maritz.com
http://www.maritz.com/
-----Original Message-----
From: Dan Jacobs [mailto:djacobs@modelobjects.com]
Sent: Tuesday, June 24, 2003 10:40 AM
To: dgraham@apache.org; 'Struts Users Mailing List'
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.
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
Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
---------------------------------------------------------------------
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 MVC design pattern is an object-oriented design pattern. It is not
inconsistent with object-oriented encapsulation!
A Struts ActionForm is not part the model in an MVC application. It's
really just an odd combination of the dismembered state of the
controller and a dismembered partial state of the view. The model, for
most Struts applications, is back in the EJB tier.
Take a look at the link at http://www.jplates.com about scriptlets. It
talks a lot about this common misunderstanding. Separation of
*independent* concerns is a driving force behind a lot of
object-oriented design patterns. But separation of object-state from
the methods that should manage that state is a violation of
object-oriented encapsulation.
Dan Jacobs
JPlates Inc.
http://www.jplates.com
> -----Original Message-----
> From: Jones, Ted [mailto:Ted.Jones@maritz.com]
> Sent: Tuesday, June 24, 2003 10:50 AM
> To: Struts Users Mailing List
> Cc: dgraham@apache.org
> Subject: RE: Object-oriented encapsulation in Struts -
> merging Actions and ActionForms
>
>
> That makes sense ...but wouldn't that break the MVC pattern
> by moving the Controller function into the Model?
>
> Ted Jones
> Maritz Inc.
> ted.jones@maritz.com
> http://www.maritz.com/
>
>
> -----Original Message-----
> From: Dan Jacobs [mailto:djacobs@modelobjects.com]
> Sent: Tuesday, June 24, 2003 10:40 AM
> To: dgraham@apache.org; 'Struts Users Mailing List'
> 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.
>
> 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
>
>
>
> Confidentiality Warning: This e-mail contains information
> intended only for the use of the individual or entity named
> above. If the reader of this e-mail is not the intended
> recipient or the employee or agent responsible for delivering
> it to the intended recipient, any dissemination, publication
> or copying of this e-mail is strictly prohibited. The sender
> does not accept any responsibility for any loss, disruption
> or damage to your data or computer system that may occur
> while using data contained in, or transmitted with, this
> e-mail. If you have received this e-mail in error, please
> immediately notify us by return e-mail. Thank you.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org