>However, I can see using the contents of the forward element as a wayto 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.
Gary, I'm not sure I follow you here. Are you saying that you think using Actions the way they are is better? Or that you'd like to have a single Action *class* which might have two methods?
I prefer using dispatch-style designs for actions myself, and I'd want to design this controller/renderer so that it could also be implemented that way. I think you're saying that's what you want, but I'm not sure.
>I don't think I agree with this, or at least, I think you have topreserve 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.
Well, I'll agree that it's coupled with the view, but I'm not sure that's the problem. There are going to be times when you have to do very specific things to achieve your goal. Coupling them with the view isn't a horrible thing if they are neatly encapsulated from other things, and that's the idea behind having a separate stage. I think it's more problematic to clutter up action.execute(...) with this stuff than to put it in a separate place.
What if struts had a visual component framework of its own...
Sounds complicated. Might be interesting. I'd like to do something sooner than later. If you have a vision for the component framework, can you help steer us on a path that gets something sooner which doesn't block the path to the more elaborate future solution?
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
