* Action Form - Form Context
How about adopting XForms (http://www.w3.org/MarkUp/Forms/) as the model for all Action Forms? This contains a model for representing everything you spoke about in your email - basically the seperation of purpose (data) and presentation. In addition, you could easily handle transformation between xml form data and business objects in special request processing commands, utilizing tools likes digester and/or existing marshalling frameworks.
Also - just for the record. Revolution not evolution :-) Chain is definitely a step in the right direction.
Another simple suggstion I would like to make (enhancement request) - it would be extremely powerful to add the property support that exists for plugin configuration, to action and request processors. This can go along way for special purpose actions. The parameter attribute is ok - but too limiting (IMO).
I have more to say.... but I'm hungry. I'll speak up later.
- Mike
Ted Husted 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]
