Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 23581 invoked from network); 15 Jan 2003 03:22:20 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 15 Jan 2003 03:22:20 -0000 Received: (qmail 3561 invoked by uid 97); 15 Jan 2003 03:23:34 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 3545 invoked by uid 97); 15 Jan 2003 03:23:34 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 3533 invoked by uid 98); 15 Jan 2003 03:23:33 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Tue, 14 Jan 2003 19:22:01 -0800 (PST) From: "Craig R. McClanahan" To: Struts Users Mailing List Subject: Re: changing ActionForm to be a Java interface In-Reply-To: <3E24BB13.5030101@modelobjects.com> Message-ID: <20030114190203.Q72826-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 14 Jan 2003, Dan Jacobs wrote: > Date: Tue, 14 Jan 2003 20:36:19 -0500 > From: Dan Jacobs > Reply-To: Struts Users Mailing List > To: struts-user@jakarta.apache.org > 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. 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: * 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). * 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. > 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 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/webtech > > > Craig McClanahan -- To unsubscribe, e-mail: For additional commands, e-mail: