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 19:57:56 GMT
>I tell you what, don't bother about it for the moment as I have 
>unfortunately no time and it looks like I should be taking this over 
>to the dev list to carry on the discussion. If I do get time soon 
>I'll subscribe to that list.

Well, I'll bother anyway, on the off chance anyone else is following, 
and in any case, to help develop the idea further.  True enough, 
though, that this probably belongs on the dev list...

>Just from a quick look at the dev list, it seems you want to put the 
>view class as the last command on the chain. I think I must be 
>missing something.

I'm not sure what you mean by this.  As it is now, I think that in 
most cases we'd want to keep the last command on the chain as it is, 
or the last two if you're using Tiles.


At 7:33 PM +0000 12/2/04, Adam Hardy wrote:
>If your view controller is actually just a command on the chain for 
>an action mapping, how would you register it against the action 
>mapping's 'input' attribute in order to get pre-presentation stuff 
>to happen for the validate-failures?

One result of a failed validation is the insertion into the context 
of an ActionForward in the same place that the result of 
Action.execute is stored, so by the time you finish the "action" 
chain and begin the "view" chain, there's no difference.  (These 
sub-chains aren't defined in struts-chain now, but I think they make 

I think you could find the view processor command by using the 
standard Chain "lookup action".  Well, out of the box, its "nameKey" 
property would depend on some String value being placed into the 
context under a certain key, and as it is now, we're talking about 
using a String property of an Object in the context under a certain 
key.  If we gave the LookupCommand an expression language (JEXL, 
perhaps?), then we could do something like this, which seems cool:


or possibly work some magic to make the "context" prefix assumed. 
Anyone  have an opinion about adding a JEXL dependency to Chain, or 
whether this would be best left to a Struts subclass of LookupCommand?

But anyway, then you'd have this somewhere else:

<catalog name="struts-view-preprocess">
     <!-- ========== Servlet Complete Request Chain 
========================= -->

            formScope="request" />

   <command className="com.example.webui.view.CPrepCommand" />
   <command className="com.example.webui.view.SomeSharedCommand" />

   <command className="com.example.webui.view.DPrepCommand" />
   <command className="com.example.webui.view.SomeSharedCommand" />


>On 12/02/2004 04:05 PM Joe Germuska wrote:
>>At 10:26 AM +0000 12/2/04, Adam Hardy wrote:
>>>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:
>>      <render
>>          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 
>>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 idea.
>>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 execute(Context)"
>>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.

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

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

View raw message