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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
