> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]
>
>
--//--
>
> The idea would be to give ActionForward a type property for a Java
> class. If the property is specified, instead of just taking
> the path as
> it stands, the Controller would call a "prepare" method on the class,
> passing it the ActionForward, ActionForm, HttpRequest, and
> HttpResponse.
> The prepare method would return a String that the Controller
> would use
> for the path.
>
> This allows the ActionForward to act as a Page Controller for
> the path.
> If the particular page referenced by the path needs any
> special "chrome"
> the Page Controller can set that up. Or, if the path needs to be
> adjusted for Locale or device (PDA, browser, et al), then the Page
> Controller could adjust the path before returning it.
>
> If it were a virtual page, like an dynamic image, merge file, or PDF,
> the Page class could also render the Response, rather than have the
> Action do it.
>
> Right now, the Action is doing double duty. It first acts as a
> Dispatcher that acquires business resources and selects the logical
> view. But, in real life, many pages often need special
> runtime resources
> of their own. So, the Action also serves as a Page Controller for the
> page it selects. Many of us consider that a mixing of
> concerns, and so
> we start to use some Actions as Dispatchers and others as Page
> Controllers. Tiles also fills this gap and is essentially a
> hybrid of a
> Compositive View and a Page Controller framework.
If an action forward requires special business requirements then
I can see both advantages and disadvantages.
The advantages is that such a new ActionForward could add
special attributes to the response that are not concerned
with the Action logic.
The disadvantages is that it is open to abuse. Bad programming
could introduce another layer of dispatching in the ActionForward
code. You would get mini-MVC nested inside another MVC, which
looks like Hierarchical MVC
>
> I'm thinking that, architecturally, the ActionForward represents some
> resource available to the application, of any type, that can
> be reached
> by the application's protocol. In an http environment, it's
> the job of a
> Resource object to provide a URI that the Controller can use
> the reach
> the actual resource. (And, in another environment, perhaps the path
> would not be a URI.)
>
> The Action, in its purest form, represents a Dispatcher. It's
> the job of
> a Dispatcher to select which (logical) Resource will handle the
> response. When we talk about selecting between "success",
> "failure", or
> "glockenspiel", we're talking about dispatching.
>
> But, in real life, we often can't just dispatch to a page. The page
> needs certain resources to render, often to fill UI controls
> like select
> lists.
>
> Ideally, I believe another class, specified by the
> ActionForward, should
> be responsible for setting up any "chrome" a particular page
> may need.
> It's the one that knows where the page is (via the path
> property), and
> so it's the one that should be privy to these details.
If you wanted to develop a "skinnable" web application for
example personalisation this new ActionForward might be the way
to go.
> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between
> "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.
>
> The "gotcha" is that, to do its job, the ActionForward type may also
> need to interact with the business layer. It doesn't seem
> right that the
> Page Controller should try to branch to another page, like an Action
> might, if there's an error. But the declarative exception
> handling might
> be able to step in here.
>
Would this new ActionForward be created each time like it is now?
Or would it become a dynamic singleton? The problem is not necessarily
interacting with the business tier, but making any such interaction
to a minimum. The probably means delegation, or caching, or something
else to add decoration. Ideally the Struts Action such grab all the
business logic for you and then store this information for you.
If you are developing a new Action Forward, may be take advantage
of this fact, and pass the business info to this new object
at construction time.
--//--
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
***********************************************************************************
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
Visit our website at http://www.rbs.co.uk/CBFM/
***********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
