> -----Original Message-----
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
>
> 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.
Partial request would also be true of rich client applications.
The bane of the web app to most business managers is the fact
that "the screen always refreshes". Putting aside the futuristic technology
that renders only sections of the browser screen, I think we should
allow for partial requests and updates. I am unsure how to semantically
describe an interface or design the abstract solution at the mo ...
> * 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.
That assumes that everything coming into the Struts Next MVC is a
XML and/or DOM. It may or may not be the case. Sounds like a very
generic request input thing X and output response thing Y going into a
Struts2 Action as part of the ActionContext though.
Using adaptors is a known solution.
XML DOM Read Adaptor -> request input thing X
XML DOM Write Adaptor <- respone output thing Y
Anyone could, then, program adaptors for whatever they like e.g flash,
HTTPServlet{Request,Response}
>
> * 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.
Egg-sactly, see above.
>
> * 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. ;-)
>
I think we need to define a feature common denominator table of
what constitutes a request and response as we know they exist now.
Secondly make a first best guess of what future next generation
would look like. Once we have this information we can define what
the interfaces are, or at least make a good guess.
For example, Http environment etc require a URL, action invocation
path, ServletContext, HttpServletRequest, HttpSession, and yep
HttpServletResponse
objects.
Then repeat the exercise for portlet jst 169 for that family.
Then anyone else who have written a bleeding edge rich internet application
can also contribute.
> Of course, this is my own itch speaking, since I live in the world of
> highly interactive browser-based applications these days...
>
One more thing: Could we finally start designing to Java
interfaces into Struts<sup>2</sup>? Ta.
interface IActionRequest { ... }
interface IActionResponse { ... }
interface IActionForward { ... }
interface IActionContext {
IActionRequest getRequest();
IActionResponse getResponse();
}
PS: Got a feeling some of this has been done within Commons Chains when
I last looked at the jarbundle/.
> --
> 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]
>
>
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447
==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
