struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [shale] Overall requirements for "remoting" feature
Date Wed, 28 Dec 2005 04:37:00 GMT
On 12/27/05, netsql <> wrote:
> >
> > The remoting support in Shale should be focused on providing
> > client-technology-agnostic mapping of incoming HTTP requests to server
> side
> > dynamic logic for AJAX-enabled widgets (including AJAX-enabled
> JavaServer
> > Faces components), plus an easy way to serve static resources (from
> either
> > the web application itself or from class loader resources) that the
> client
> > side widgets might require.  This support must operate in either a
> servlet
> > or portlet environment, and require minimal (ideally none in the
> simplest
> > case) configuration at the application level.
> >
> Great, but there are other remoting types, like AMF, Soap, etc. Could
> other protocols be pluged in to request and return from chain?

The current remote implementation can already do this.  Nothing changes with
the proposed implementation, except that you will not be *required* to use
Commons Chain as your implementation technique.

And other "ui" of course other than (short lived I predict)
> JavaScript/DHTML.
> JDNC, Flash components (flash 8.5 has a cool new VM)
> If I plug in the ADF, could I process flash requests? I don't
> need you to implement it, as long as there is a "plugin" mechanism,
> especially for binary protocols.

The current mechanism, and the proposed mechanism, both support binary
protocols as well ... by virtue of providing you access to an underlying
output stream instead of a writer, which can be used to create the
response.  Indeed, this will be necessary to correctly serve static images
(which cannot be reliably delivered via any sort of text stream) already.

> >
> >
> > * (Optional) alternative dynamic execution mapping to execute a Commons
> > Chain command
> >   (essentially equivalent to the current functionality, and/or a tie-in
> to
> > Struts Action Framework 1.3.x
> >   type processing logic).
> >
> > * (Optional) alternative dynamic execution mapping to execute an XWork
> > action (essentially
> >   equivalent to what WebWork currently does for mapping incoming URLs to
> > business logic).
> >
> Great that WebWork and "Clasic" are in there or could be pluged in.
> Ideally Shale is JSF centric but allowed other view types (and remoting
> protocols)

That's definitely an advantage of adding this particular level of
absraction.  It lets you mix and match server side technologies for the
types of responses you need for particular URL patterns.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message