Adding to 3), it would be interesting to add "dialog" scope, something Shale is working on for a scope that is for a logic process where multiple instances might exist in a single session (think browser cloning where two of the user's browsers are going through the same workflow).
I think this all sounds interesting, but I think the more we start to blur the lines between forms and actions, the more we are going to have to put a lot of special casing across several commands in a not-very-encapsulated way to deal with:
1) if it's a form, scope means get one kind of thing from one kind of scope; otherwise assume it's a POJO and get it somewhere else.
2) if the action mapping specified a form, then validate it one way; otherwise, introspect for a validate method (and besides, if it's a POJO, you shouldn't have to implement a specific validate method, so now you have to specify two methods in the action mapping, one for validation and one for execution)
3) if the action mapping's type is an Action, then call it's execute method. Maybe if the action mapping is a Command, call a different execute method; finally, if it's a POJO, call the method specified in the config file.
This suggests that if we want to support this, we instead change the chain config. We could make a "preprocess-action" chain which encapsulated these:
<lookup catalogName="struts" name="servlet-standard-preprocess" optional="true"/>
SelectLocale"/>
RequestNoCache"/>
SetContentType"/> SelectAction"/>
AuthorizeAction"/>
followed by some choice to call either "process-action" or "process-pojo", where "process-action" is these commands (what would remain in today's config after moving the above):
CreateActionForm PopulateActionForm ValidateActionForm SelectInput ExecuteCommand SelectForward SelectInclude PerformInclude CreateAction ExecuteAction
and "process-pojo" could string together some of the same commands, but deal differently with the various special cases. Exactly how we would determine the need to branch would be open for discussion.
What I don't want is to get stuck trying to hash out a lot of radical extensions and delay our ability to build a stable backwards compatible release upon which people will be willing to build some apps and give us some solid debugging information. Let's try to figure out a good balance that keeps these routes open until people have time to write code for them without getting stalled.
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]
