Hi Craig, Thanks for your prompt response. My comments are mixed in below.
Craig R. McClanahan wrote:
Well, I understand your point, but I don't agree with the idea that an enabling technology should prevent competent and conscientious engineers from being competent and conscientious, just because other folks might display incompetence. They probably will anyway.On Tue, 14 Jan 2003, Dan Jacobs wrote:Date: Tue, 14 Jan 2003 20:36:19 -0500 From: Dan Jacobs <[EMAIL PROTECTED]> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: changing ActionForm to be a Java interface Hi all, I know this is very late in the 1.1 game to change things very much, but I'd like to make an API change request. Currently, ActionForm is defined as a class rather than as an interface. The problem with that is that it doesn't allow other kinds of objects to act as ActionForms.It's not going to happen -- absolutely positively not for 1.1, and (pretty much) over my dead body for any subsequent 1.x release. I'm taking advantage of the single inheritance restriction of Java to make it more difficult for most people to do things that they should not do.
I remember that, and I was puzzled about the change at the time. I feel pretty strongly about the sanctity of model objects myself (enough to choose it as my company name), and I completely agree that ActionForms should never be confused with models. On the other hand, it would be handy if they could at least help out with the rendering. :-)A bit of history -- up to Struts 0.5, ActionForm was indeed an interface. The problem is that *way* too many people tried to use the ActionForm as a value object, which was wrong for two reasons:
I suppose this is the point that a lot of Struts users don't fully take to heart, and I agree it's one of the things that Struts does very well that other systems do very poorly. But I doubt that providing an interface along with a default implementation would do much to strengthen or weaken people's understanding of the concept.* It encouraged you to make the property types match the underlying business tier instead of Strings, which violated one of the primary purposes for ActionForms in the first place (the ability to reproduce invalid input, which is a fundamental user expectation).
I'm kind of a roles and responsibilities guy. In my experience, things don't get chronically misused when those two are done just right. In this case, I'm not sure what could be done to improve it though.* It tied your business tier to Struts APIs, which meant you had to import things like servlet.jar into places that it has no business at all. Because it was obvious that people were going to misuse the Struts APIs in this way, I switched ActionForm to being a class instead. People still try to misuse it :-), but most of them find it easier to do what they really should do in the first place -- use plain old JavaBeans (POJOs) for value objects.
Well, like I said, I use JPlates easily in place of JSPs for rendering, because JPlates comes with a dispatching servlet similar to yours, allowing JPlates to be addressed using URLs just like JSPs. So in that way, JPlates works with Struts just as well as Velocity.In particular, I want to be able to use JPlates objects (see http://www.jplates.com ) as ActionForms, since that would allow me to encapsulate the full behavior of a form in the object, instead of just having a place to put the data. I can already use JPlates in place of JSPs for rendering (which is wonderful!), but I'd have a more consistent solution if I could use JPlates objects for my ActionForms as well.Can you use the "nested" facilities to make this integration happen one layer deeper? In other words, you can define an ActionForm (or DynaActionForm) with a single nested property that points at your JPlates objects, or otherwise wraps them? I also find it interesting that the JPlates docs think that their technology will work just fine with Struts, without making this kind of a change ...
For ActionForms, though, I can only use JPlates instances by delegation from an anstance of an ActionForm subclass, which is ok, but not idea. I'd rather be able to implement IActionForm from a JPlates class and delegate to an ActionForm if necessary.
For the sake of compatibility with existing Struts applications, what I propose is: 1. interface IActionForm (yeah, I don't like that convention much either) would define the interface methods. 2. class ActionForm implements IActionForm would be used pretty much the way it's used now. 3. the internals of Struts would be changed to use IActionForm wherever ActionForm is currently used. 4. other kinds of objects could implement IActionForm directly or by delegation to an ActionForm. I'd be happy to help out to make this change. Dan Jacobs President, ModelObjects Group http://www.modelobjects.com Chairman, Boston ACM WebTech Group http://www.acm.org/chapters/webtechCraig McClanahan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
