struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: view controller
Date Wed, 01 Dec 2004 11:13:47 GMT
On 11/28/2004 04:40 PM Joe Germuska wrote:
> At 11:31 AM +0000 11/24/04, Adam Hardy wrote:
>> On 11/23/2004 02:20 PM Joe Germuska wrote:
>>> Your action isn't executed if validation fails.  However, the 
>>> validation is performed on a second request, so the object placed 
>>> into the scope before the form was presented is no longer there.
>>> If your categories are really relatively static, consider managing 
>>> them in Application scope rather than request.  I often have one or 
>>> more plugins which initialize common menus like states and provinces 
>>> or months of the year and place them into the application scope (I 
>>> like to use the DigestingPlugIn).  Your code doesn't look like 
>>> there's anything particularly request-sensitive about the category tree.
>>> Some people make lists a property of the form itself.  This is also 
>>> one of the core use cases for some kind of view controller registered 
>>> against the input forward's path, which is one of my goals to 
>>> implement in a Struts 1.3.x timeframe.
>>> Joe
>> Joe,
>> I hope you don't think I'm labouring a point after the big discussion 
>> last week, but regarding a view controller registered against the 
>> input forward's path, I just don't get the paradigm.
>> It seems like an unnecessary complexity when you can do what Matt 
>> suggested and point the input attribute at a 'loader' action mapping.
> As Struts is designed now, setting the "input" attribute of an action 
> mapping to point to another action mapping results in two passes through 
> the request processor for a single HTTP request.  This is not a use case 
> for which Struts is designed or tested, and which could have strange 
> side effects.  Certainly, many people use it today without problems, but 
> why not move Struts towards a clearly defined usage pattern which 
> doesn't involve any grey areas like this?
>> Having a loader action decouples it from the validation+processing 
>> action, which seems friendly and OO to me. Then you can use that 
>> loader action from anywhere - can you say the same about your view 
>> controller registered against the input forward path?
> When I say that it's registered against the input forward path, I don't 
> mean that it's connected to the validating action mapping.  I mean that 
> the system is configured so that any time it is headed to the path 
> defined as the input forward path, it will execute one or more view 
> controllers.  Therefore, it doesn't matter whether you are presenting 
> the form for the first time or on a subsequent pass; the view controller 
> code would still be executed.  To me this seems "more OO" because it 
> associates the processing code with the context in which it is used.  No 
> one needs to remember a sequence of actions which must be chained; they 
> just trust that the request context (including the session and 
> application) have the right data in the right places, and then small 
> adjustments necessary to rendering the view can be encapsulated cleanly.
> Does that help at all?
> Joe

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.

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.

Do you see what I mean?

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

View raw message