As I have been working with Maverick in the last few weeks I am noticing that in order to build up base functionality in my controllers I either have to do a fair bit of subclassing or else I duplicate a fair bit of code. As we've already discussed chaining controllers allows us to do more with composition and keeps the design clean. Using a document view to point to another controller works well to tag on an additional controller for a command and while the syntax of maverick.xml will support a more complex implementation of chained controllers (see below), I wonder if perhaps there may be a better way to represent these relationships and clarify when we are making the transition from controller to view. If so perhaps we could (minimally) come up with an XSL to use with maverick.xml since it supports the transform-before-load (great feature!) or else a special controller / XSL combo that would handle this more cleanly.
To illustrate what I mean by "more complex implementation of chained controllers" I will describe an app I am working on. My inheritance hierarchy is currently several layers deep and will be getting deeper all the time. I start with a simple Throwaway style controller with a few quirks, subclass and create a controller which handles basic bootstrapping functionality for our app, subclass and create a controller which handles some user authentication odds and ends, subclass again and create a controller for use with secure pages. On top of that I will need to build controllers for each module of my application since each module has some common functionality and then subclass each of these for individual pages. At this point the hierarchy is deep enough that it feels like a design problem, so I'd prefer to beak this up into separate controllers that call one another. Each command would then call several controllers to handle bootstrapping and authentication functions, then another for module specific setup and then a final controller (or controllers) to handle processing forms, applying business logic, preparing the model and selecting the view to render. In maverick.xml this would look like: (simplified somewhat) <!-- command 1 --> <command name="myCommand1"> <controller class="com.foo.Bootstrap"/> <view name="continue" path="authenticationCheck.m"/> </command> <command name="continueCommand1"> <controller class="com.foo.Command1"/> <view name="success" path="myPage.jsp"/> <view name="error" path="errorPage.jsp"/> </command> <!-- command 2 --> <command name="myCommand2"> <controller class="com.foo.Bootstrap"/> <view name="continue" path="authenticationCheck.m"/> </command> <command name="continueCommand2"> <controller class="com.foo.Command2"/> <view name="success" path="myOtherPage.jsp"/> <view name="error" path="errorPage.jsp"/> </command> <!-- utility controllers do not call directly! --> <command name="authenticationCheck"> <controller class="com.foo.AuthenticationCheck"/> <view name="continueModule1" path="moduleSpecific1.m"/> <view name="continueModule2" path="moduleSpecific2.m"/> </command> <command name="moduleSpecific"> <controller class="com.foo.ModuleSpecific1"/> <view name="continue_command1" path="continueCommand1.m"/> <view name="continue_command2" path="continueCommand2.m"/> </command> So the flow is: 1. myCommand1 (Boostrap) --> 2. authenticationCheck --> 3. moduleSpecific --> 4. continueCommand2 The obvious consequence of this design is that the entries for our commands become obscure. One has to do a fair bit of reading to see that the real work for the command "myCommand1" is handled primarily by the com.foo.Command1 controller. Furthermore, the authenticationCheck controller needs a view for every module-specific controller, and each module-specific controller winds up requiring a view entry for every page controller in the module. (to be continued) John-Mason Shackelford Software Developer NCS Pearson - Measurement Services 2510 North Dodge St. Iowa City, IA 52245 319-354-9200x6214 [EMAIL PROTECTED] **************************************************************************** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. **************************************************************************** ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp [INVALID FOOTER]
