While I don't disagree with any of Ted's points, I do think that we need to expand our horizons with Struts Next, rather than just provide more of the same. We need to move beyond the traditional web app and embrace the next generation of web apps that have some rather different characteristics. For example:
* Many - perhaps even most - requests are not page-replacement requests. That is, the response is not a complete HTML page or frame to replace the one the request was submitted form. * The request may not have come from a form or a link; it may have been submitted using an XMLHttpRequest object. In such cases, forms as we talk about them are not relevant. Instead, we may want to provide the request input in the form of a DOM. We may also want to think about how to handle input validation in a consistent way across different types of requests. * The response may not correspond to a page or a frame. Instead, it might be destined for a particular piece of the page (e.g. a div element). This allows for partial page updates in interactive applications. * The response may not be HTML, even when it's headed for the browser. It might be XML or even JavaScript code, serialised from a data structure, and to be interpreted / evaluated in the browser. Not all of these will have a direct impact on the Struts Next core, of course. However, I do want to make sure we are thinking about next generation apps as we build our next generation framework. ;-) Of course, this is my own itch speaking, since I live in the world of highly interactive browser-based applications these days... -- Martin Cooper On Sun, 10 Oct 2004 15:42:10 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > To follow up some other threads about the "architectural vision" for Struts Next, > I'd like to offer the following: > > ---- > > Most of us are torn whether to create Struts Next by evolution or revolution. I > think what most of us revolutionaries really want to to create Struts Next by > mutation. We're not displeased with Struts 1.x. It's just that we are still carrying > around an appendix or two that muddle our "clear vision" of the Struts 1.x > architecture. > > For Struts Next, whether we get there by evolution or mutation, I would envision > three pillar components: > > * Request Processor > * Action/View Context > * Form Context > > --Request Processor-- > > The core of the Struts core is now, and has always been, the Request Processor. In > Struts 1.0, it was buried amongst other methods in the ActionServlet, but you could > see that it was there. In Struts 1.1.x, we pulled it out for all to see. In Struts > 1.3.x, we're installing a revolutionary Request Processor based on Commons Chain > <http://jakarta.apache.org/commons/chain/>. > > For Struts Next, I'd imagine we'd continue using and refining the Struts Chain > Request Processor. The (ironically-named) Chain gives us the flexibility to make > Struts less like a framework and more like a toolkit for building frameworks. For > example, in Struts 1.3, we already plan to offer an alternate Command Catalog that > supports portlets. > > --Action/View Context-- > > The hand maiden of a Chain of Responsibility is a Context. We've been batting around > the idea of an ActionContext for some time. Joe brought it up again the other day. > The basic idea is simple. Instead of passing around several members in a signature, > we put them all in a JavaBean and Context, and pass this around instead. > > The idea of a ViewContext is similar, except that it is designed to expose > everything a View would want to know about Struts as a single, coherent JavaBean or > Context. > > There was an experimental implementation, called the ConfigHelper, in February 2002 > > <http://tinyurl.com/3t3m9> > > which was used as the basis of the ActionConfig of December 2002 > > <http://tinyurl.com/3jwpj> > > In Struts Next, I would imagine that an ActionContext is used internally by the > RequestProcessor and a ViewContext is exposed to the page or dialog. The difference > being that the ViewContext would free of web semantics, so it could be used without > change on any platform. > > --Form Context-- > > We have a love/hate relationship with ActionForms. One of the big things Struts > Chain buys will be the ability to easily change how automatic population takes > place. If you don't like that link in the chain, you can change it just by changing > the default XML catalog descriptor. > > The ActionForm filled a lot of roles in Struts 1.x, and I think some people will > want to keep it. I've also used WebWork type frameworks. They are simpler than the > Struts Action/ActionForm combo, and in some ways better, but there are still pieces > missing. > > IMHO, what we need is a complete metadescription of the UI controls and forms > (collections of controls) an application is using. If we combine the DynaActionForm > with the ValidatorForm, we already have 80% of what we need. But, I believe, we > should also be able to define a default control, a UI label, a UI "hint", and a > default conversion/transformation method. (The latter is already implied by the > validation.) > > The end game should be that if we pass this description to a smart control, it > should be able to render a basic input or output form. > > Of course, basic is never good enough, so we would also want to be able to pass it > to individual controls who would render part of the form. But, the proof of concept > should be: > > <struts:form readonly="false"/> > > and have a complete input form, with labels and hints, dropdown lists, and or > > <struts:form readonly="true"/> > > and get the non-input version. > > The conventional Struts paradigm would remaint the same. But instead of controls > looking to the request, session, or application contexts for a JavaBean/ActionForm, > they would look to the ViewContext for a FormContext (or collection of > FormContexts). But the FormContext would not only carry the value of the control, > but its label, hint, and other attributes. > > Another important role for a FormContext is to serve as a JavaBean factory. What > most of really want to do is to say to a *valid* FormContext: "It's great that the > input is valid, now can I have those values in a business object, please". > > The idea being that if we specify in the XML descriptor what type we want each > (string) attribute of the FormContext to create, and the context could then create > the target type for each attribute and us them to populate a JavaBean, and return > the populated instance, ready to hand off to your business logic. (Something like a > JSF Managed Bean.) > > The FromProc tool in SourceForge does this sort of thing now > <http://sourceforge.net/projects/formproc>. Instead of just validating the input, as > we do with the Commons Validator, it validates the input and then converts it to a > target object. > > --Testability-- > > A fourth pillar has to be testability. The original Struts implementation was > created just before the interest in JUnit began to peak. Struts Next has to be > testable from square one, and we must avoid any designs which are difficult to test. > > -- > > Personally, I believe the original Struts scenario is sound, which is why it has > lasted so long. > > (0) Client submits request > (1) System receives the incoming request > (2) System transfers matching values to a form object > (3) System validates the object > (4) System branches to success or failure. > (4a) On success, system executes/delegates the business logic. > (4b) On failure, system returns the faulty input. > (5) A view displays the nominal result or redisplays faulty input. > > We just need to identify what improvements we need to make at each step, and any > additional steps we'd like to add. > > It might be interesting to expand this quick list into a formal set of use-case > scenarios. If you have UML Distilled, Fowler mentions scenarios at the opening of > Chapter 3. > > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
