I believe that Tiles is exactly what your looking for in converting your template method approach to struts. Cedric has done an outstanding job with the implementation. (Thanks Cedric, this is light years above the original template tags!)
BTW, don't discount the struts-user list for design questions. I actually believe that there are a bunch of great design questions asked and answered there. Don't get me wrong it's great to get a view from the committers, but everyone on the user list is considered a contributor. (Well, at least IMHO.) Oh BTW, Cedric does a great job of supporting Tiles. I'm convinced that he and many of the other committers never sleep! That said, if this doesn't generate enough of a response you may want to consider asking this on the user list. Steve ----- Original Message ----- From: Heath Chiavettone Sent: Wednesday, March 13, 2002 11:34 AM To: '[EMAIL PROTECTED]' Subject: Question about design migration to struts Hello, I hope this is the correct forum for this. I wanted to get the opinion/knowledge of the struts contributors on this one. If it isn't go ahead and move it to the struts-users list. I am investigating porting an existing Model 1+ JSP implementation to Struts and Model 2. I call it Model 1+ because our application was based on the template design pattern described in this article (http://www.javaworld.com/javaworld/jw-01-2001/jw-0119-jspframe_p.html <http://www.javaworld.com/javaworld/jw-01-2001/jw-0119-jspframe_p.html> ). We expanded the pattern significantly in our application, substituting custom tags for "included javascript" methods described in the article. The essence of the design is that each JSP is mated to a JavaBean. The java bean contains the data, and all business logic. After the bean is initialized on the JSP page (this involves giving the bean access to the request and response)and the <jsp:setProperty */> tag is performed for the bean, the bean's process method is triggered through another custom tag, which wraps the JSPs' actual html output. This method triggers the data initialization or validation and business processing logic (based on display or form submit) and then based on the data, redisplays itself or redirects to the appropriate JSP. So in a sense, we mostly need to carve up our JSP beans into ActionForm and Action objects, do some cleanup, set up the struts-config.xml, and use the struts tags in our JSPs. Where I'm having trouble is related to a decision we made regarding how we handle "component" jsps. What I mean by this is in many cases we have encapsulated reusable components within our application as their own separate Model 1+ JSPs, and dynamically include them into parent JSPs where necessary. To support this, I extended our pattern to understand this parent/child, container/component concept. As a result, the parent is able to validate the data of the component JSP, without having to "include" that component. Another factor I'm dealing with is the fact that we sometimes nest these components several layers deep. I believe that re-factoring our JSP/JavaBean into Struts, while a bit of work, seems to be the right approach. My only problem is trying to figure out what to do with our component JSPs. In an ideal world I could just re-factor them the same way and use them as I am now. But I don't think that is the case. My next thoughts were to have my parent JSP's ActionForm objects contain the ActionForms of the components it uses, and the Action trigger the components Actions. But I don't think Struts would nest the property settings into these contained forms (am I wrong?). I would then use Arron Bates' Nested tags to access the contained ActionForm objects of the parent within the component JSPs. I recognize that this hard-codes the JSP component hierarchy into the Actions and the ActionForms, but I'm willing to live with that in the short run until I can figure out how to move it out into some XML configuration file (perhaps struts-config?). So now for my questions: 1. Will struts nest the property setting into an ActionForm if it detects a property that IS an ActionForm? 2. Has anyone else dealt with this kind of problem before? 3. If so, do you have any suggestions for an alternative? 4. Is it possible for me to extend the struts-config.xml DTD to allow the definition of nested ActionForm/Action? 5. Is this something that would be considered useful for the mainstream struts world? Thanks for you consideration and help... Heath Chiavettone.
