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
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
