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>
All well and good.
The ViewContext is responsible for the output is an Action. Is that what you
are saying?
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.
This does sound like JavaServer Faces to me. It is an another intermediate
rendering language
expressed as Java object. Sounds to be like reverse of the Element Construction Set
(ECS)
again but in abstract 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.
Ok in the HTTP environment, I think you pushing an old idea that we pass context around
instead of long parameter arguments. So one of these contexts FormContext and/or
ViewContext, a subclass implementation, will hold the HttpServletRequest and
HttpServletResponse objects etc. Is this how it works?
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.)
Yes by gum I was right about JSF incluence. If you are going to create JavaBeans,
what
about creating beans by proxy such as IoC container. In your FormContext bean creation
message thing, I would hope that you divorce the actual creation logic, so one can
plugin there own service assembler.
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.
What happens if your object is expensive to create?
--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.
Outside of container test is a boon. Pushing the submit from the command line or
DOS prompt
is lot easier than firing up tomcat or redeploying to web logic each time.
The other thing I would add is strong debuggability. Is it true that Tapestry's web
debugging is the best of the current crop of web application frameworks?
--
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]
--
Peter Pilgrim
__ _____ _____ _____
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___//____//____//____/ + Intrinsic Motivation
On Line Resume
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
