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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
|