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:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 11:06 AM > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > __________________________________ > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
