On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter
<[EMAIL PROTECTED]> wrote:
> > -----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 ...
It's not futuristic, it's real today. I have shippng product as proof. ;-)
> > * 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.
Not at all. It just means that certain mappings might be configured to
accept XML input while others might accept the kinds of requests
Struts handles today.
> 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
Just to be clear, I am not suggesting that a request in the form of
XML implies a response in XML. The response might still be HTML, or
even JavaScript. (But perhaps you were not suggesting that either.)
> 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.
You mean JSR 168, but yes, agreeed.
> Then anyone else who have written a bleeding edge rich internet application
> can also contribute.
That's what I do in my day job these days, hence the itch I mentioned below. ;-)
--
Martin Cooper
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
