struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [shale] Overall requirements for "remoting" feature
Date Wed, 28 Dec 2005 04:52:59 GMT
On 12/27/05, JEEVANATHAM P. /BPCRP/INFOTECH/VASHI <
jeevanantham.p@3i-infotech.com> wrote:
>
> Dear Craig,
>
> I am new to shale and AJAX also.
> I done validation using AJAX and shale successfully.
> Also I want use same technique to the whole application. That is to
> navigate
> page also.
> Please let me how can we do that using "remoting" concept.


"Navigation" is sort of an interesting concept, in the context of this
discussion  It really depends on what you are trying to do for an overall
application architecture -- are you stcking with a traditional MVC
organization where the controller is on the server (typical of nearly all
Struts or JSF apps today), or are you tending towards the "entire
application in one page" approach that becomes technically feasible with
AJAX techniques?

For the former case, JSF today only supports navigation on a per-page
basis.  Therefore, you'd want to use standard JSF techniques to submit the
entire form, and have your action method return an outcome that drives the
standard JSF navigation rules to switch to a different page, rather than
trying to use asynchronous requests (mapped to business logic by the Shale
remoting support) for that purpose.

For the latter case, if you go clear to the "one page" extreme, there is no
such thing as navigation (in the traditional webapp sense) any more :-).
Instead, you'll need to find some reasonable controller architecture
implemented in JavaScript that you can include in your overall page -- and
it would help you dynamically manipulate the content of the HTML DOM, in a
manner quite similar to what you'd do in a Swing app when you open and close
dialogs.  Even in this latter extreme case, Shale's remoting support can be
useful ... but best practices would be around using it to remotely access
model data, rather than remotely generate UI markup.

The architecture designs in between these two extremes, however, are not
well defined at the moment.  It will be interesting to see how that all
plays out.

Thanks & regards,
> jeeva


Craig

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