--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> Just a little "me-too" here, but I think both Ted and David have good 
> points.  Ted's approach to adding a controller to the ActionForward 
> is a relatively small change to the infrastructure that can offer a 
> lot of gain.   And I've been interested in seeing some kind of 
> ActionContext class for quite a while now.

I chose my words carefully when I said "ActionContext interface".  I
*think* we can all agree that if we added this it should be an interface
:-).

David

> 
> Joe
> 
> 
> At 6:47 -0700 8/11/03, David Graham wrote:
> >--- Ted Husted <[EMAIL PROTECTED]> wrote:
> >>  David Graham wrote:
> >>  > What I think we're seeing here
> >>  > is that we've outgrown our ActionForward declarations and need
> some
> >>  new
> >>  > ones.  I'm fine with adding a SuccessAction but would really like
> to
> >>  see
> >>  > us discuss future possibilities in this area.
> >>
> >>  This may not be what you meant, but I've been thinking that
> >>  ActionForward could use a class extension point, same as
> ActionMapping.
> >>
> >>  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.
> >
> >This may be a good time to add an ActionContext interface instead of
> >passing all these individual pieces.  This would also slightly remove
> the
> >dependence on Servlet to allow us more flexibility when we look at the
> >Portlet API.
> >
> >>
> >>  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.
> >>
> >>  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.
> >>
> >>  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.
> >
> >I've had similar composition problems and agree that a separation makes
> >sense.  Tiles Controllers can be used to setup page data but that
> doesn't
> >always work (especially if you're not using Tiles :-) so I end up
> chaining
> >actions.  None of the action chaining is due to bus. logic as that's
> >properly factored into a Service layer; it has to do purely with
> setting
> >up page data.
> >
> >Tiles Controllers are one of the major reasons I use Tiles and I think
> >it's appropriate to move that concept into the Struts core.
> >
> >David
> >
> >>
> >>  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.
> >>
> >>  -Ted.
> >>
> >>  --
> >>  Ted Husted,
> >>     Junit in Action  - <http://www.manning.com/massol/>,
> >>     Struts in Action - <http://husted.com/struts/book.html>,
> >>     JSP Site Design  -
> >>  <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
> >>
> >>
> >>
> >>
> >> 
> ---------------------------------------------------------------------
> >>  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>  For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! SiteBuilder - Free, easy-to-use web site design software
> >http://sitebuilder.yahoo.com
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -- 
> --
> Joe Germuska            
> [EMAIL PROTECTED]  
> http://blog.germuska.com    
> "If nature worked that way, the universe would crash all the time." 
>       --Jaron Lanier
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to