>>I'd be concerned about associating a form with a ForwardConfig. It's >>possible that the resulting view could contain more than one form needing >>prepopulation... I >>personally have come across this scenario multiple times in multiple web >apps >>I've been involved in.
>Good point; I haven't faced this myself, but I agree we should try to >design to support it. >I don't think I like the chaining idea; it just doesn't seem clear -- >but I don't think you're advocating it as much as floating it. >However, I can see using the contents of the forward element as a way >to provide more than one form bean to the renderer. I'll think about >this some more. How would you actually make them available to the >renderer? Via a map? Expect the renderer to fish them out of >request or session scope? I prefer making a single action have the responsibility of staging the data for the view and handling the events resulting in a page submit. Like the DispatchAction and the LookupDispatch action the appropriate methods in a view controller could be invoked depending on a command argument or the button that was invoked to submit the page. >I don't think I agree with this, or at least, I think you have to >preserve the possibility that different actions would want to use the >same form definition in different scopes. I don't think that would >be a very good design, because of the risk of confusion, but I'm not >ready to say we should block it. I think the problem with creating a page controller is that it is coupled with the view. The component aspect of JSF seems very attractive but it would be nice if it was a solution built around the struts model and not made to fit. What if struts had a visual component framework of its own and the page controller was responsible for loading the metadata the components would use into scope and assembling associated model classes that the components would hook into. The view model/events might best be used for constructing the view (unlike JSF). As the visual components are rendered, callback events to the model could effect the rendering phase. Leave the rest alone letting struts map values into a single formbean. The visual components could be constructed as view helpers that could be used in jsp scriplet, custom tags or velocity templates. These component helpers would be like smart collections that would use the metadata to make rendering decisions. This would keep the conditional view logic out of the presentation. Let the page controller/struts action handle delegating to a command listener. >Obviously we can't move the scope setting without sacrificing >backwards compatibility -- that is, we can't move it at all, since we >won't sacrifice compatibility -- although we could have a default >scope on the form bean if that were helpful. I'm not sure I see that >it is, but we can see... Gary --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
