struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: view controller
Date Thu, 02 Dec 2004 16:05:22 GMT
At 10:26 AM +0000 12/2/04, Adam Hardy wrote:
>OK, I understand now. :)
>I'm intrigued to know how you would declare the view controllers and 
>register them against URLs. It would be in struts-config.xml 
>presumably. Would you be able to register them against a tile def? 
>Would the view controller have the same method signature as the 
>action execute()?
>Have you actually got anything in the nightly build yet?

No, nothing yet.  The first order of business is getting the chain in 
there, and action on that is waiting for the full release of Chain 
1.0.  I'm thinking about the issues and looking for challenges while 
we wait.

As for anything specific to a view controller -- well, I'm not sure 
how it would be configured, and I consider that important.  In a 
project here, we have a class we call "UIToolKit" which has a 
collection of "renderers", and then we have a "PagePrep" chain 
command which operates between "ExecuteAction" and "TilesPreProcess". 
(This allows the controllers to be registered against tiles paths, 
although now that I think of it, it is probably only operating for 
the "master" or top-level tile.

The renderer config looks something like this:

		 path		=".configure.SelectTopicsOrModel"
		 type		="....ConfigureRenderer"
		 method	="selectTopicsOrModel"
		 form		="configure_SelectTopicsOrModel"
		 scope   ="request"

where "path" is compared to the return value of "getPath()" called on 
the ActionForward which was returned by the Action class.  "type" is 
a class, and "method" is a method on the class; for our local use, it 
is understood that the method will take a single "RenderContext" 
argument.  "form" and "scope" are optional, but if defined, they will 
be used to put a form into the RenderContext so that prepopulation 
can occur.  The RenderContext also has references to the request, 
response and other application classes which may be necessary to do 
the prepopulation or other view preparation.

I'm not specifically proposing this for Struts at all, but only 
offering it so that people can critique and consider some of the 
issues we've covered here in a "prototypical" implementation of this 

The RenderContext would probably be replaced by a class called 
"ViewContext" which has been discussed recently on the dev mailing 
list, and fairly thoroughly elaborated on by Ted Husted.

Moving forward, the main question is whether it's even worth creating 
a new area of struts configuration for this, or whether it would be 
more suitable simply to advise people to configure chain commands 
which do the same thing.  Ted's idea is that "ViewContext" would be a 
subclass of Chain context, so the structure of any view controller 
class would be pretty similar to a Chain command: "public void 

What might make more sense would be to create an abstract Chain 
command which knows how to look up a form and put it in the view 
context, and then users could extend it and implement their view 
preparation.  We didn't do that here because we were still very new 
to Chain, and we weren't yet comfortable with the chain configuration 
syntax.  But as this is taking shape, and as I'm writing this, I 
think I'm leaning towards just doing it with Chain, especially for 
starters.  The Chain model was recently extended to make it easier to 
manage a map of named command catalogs, so that you wouldn't have to 
cram everything into a single mega-config file.

And, of course, something we've been noticing is that using chain, 
Actions themselves could be directly replaced with chain commands, 
once people become comfortable with chain configuration.  But one 
step at a time!  The initial chain implementation is totally 
backwards compatible with old Struts config files.


On 12/01/2004 02:37 PM Joe Germuska wrote:
>>Yes but only half. Regarding the first point, since struts is 
>>actually able to accept and deal with a second action mapping in 
>>that mapping's "input" (or "forward") param, then somehow struts 
>>must be designed for it. It can't possibly have been a happy 
>>coincidence, surely? I don't know about tests.
>Not really; it's just a side effect.  Struts is merely calling 
>requestDispatcher.forward(...)    If Struts were designed for it, 
>you wouldn't be including the ".do" in the value of input, in the 
>same way in which you don't have to include it in the "action" 
>attribute of an html:form tag.
>To say that Struts isn't "tested" for it may be overplaying the kind 
>of testing we have, but it is true that in general, action chaining 
>is considered "unsupported."  As you'll see below, deeper changes 
>underway in Struts should obsolete the need to chain using multiple 
>calls to requestDispatcher.forward(...) (with repeated runs through 
>the entire request processing cycle).  The whole request processing 
>cycle is going to be much more open and flexible.
>>I appreciate your direction though. Do you envisage being in a 
>>position to completely disable chaining in struts? Let me describe 
>>the situation I had at my last project where it was useful (and 
>>justified IMHO):
>>The screens were complex and were not under my control. Each screen 
>>contained up to 3 completely seperate bits of functionality, e.g. 
>>hotel bank account number, hotel billing address and hotel billing 
>>options. These were handled by different session facade calls.
>>I had already experienced alot of scope creep and I knew that these 
>>would change, and in fact I was pushing to get control of the 
>>screen designs, in which case I would simply have put the 3 
>>different bits on different screens - so when coding the mappings, 
>>I made 3 mappings and chained them together, so I could seperate 
>>out the Action classes and hopefully actually seperate out the page 
>>too in the future.
>>I didn't get the opportunity to seperate out the pages, but I was 
>>still happy that I could chain the mappings and have seperate 
>>Action classes.
>I think that this is a good use case for the commons-chain library, 
>and probably for the "ChainAction" that Craig recently wrote.  The 
>ChainAction is meant as a way for users to delegate Action 
>processing to a commons-chain command (which itself may be a chain 
>of commands) in a way that would have allowed you to rearrange the 
>"plumbing" just by editing config files.  Using these things right 
>now is still a little cutting-edge, as there is still a lot of 
>documentation to write, and probably some better support for 
>multiple chain-configuration files...  we're hoping to push these 
>things into the Struts core CVS as soon as commons-chain makes its 
>1.0 release (any day now).
>Strictly speaking, this is all kind of tangential to a view 
>controller, and in fact, if you were using ChainAction, you could 
>slot in commands that each had any balance of responsibilities 
>between "action processing" and "view preparation" that you liked. 
>We might find ourselves looking for some good ways to standardize 
>things like instantiation or location of the form bean which might 
>need to be prepopulated for the destination view, which is one of 
>the reasons I like the idea of formalizing view preparation.

Joe Germuska       
"Narrow minds are weapons made for mass destruction"  -The Ex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message