Hi Joe,
I've also been interested in these discussions, though our earlier discussions revolved around the old RequestProcessor. I haven't had a chance to try out the shiny new chain (or is it still rusty and needs some polishing?), so lately I've been limited to lurking.
I would expect that the chain still has some considerable evolution ahead of it. I think once we establish "ActionContext" and "ViewContext" classes and reorganize things so that these are created and populated and passed along to the action and view chains (which now simply all get a commons-chain ServletWebContext), then things will be essentially stable. In so far as that may change or obsolete existing commands, I wouldn't want to promise to maintain backwards compatibility, so using this stuff now is pretty much signing up for tracking a bit of change.
That said, it works, and it is always helpful to have more people using it, testing it, and providing feedback on it!
The <render> element you shared in an earlier email listed the form name along with the path. To support the possibility of multiple forms, I think the form information can be nested in another element.
from<render path =".group.SelectDealers" type ="x.y.z.webui.GroupRenderer" method ="prepareSelectDealers" form ="dealerSelectionForm" scope ="request" />
to <!-- render a page with one or more forms --> <render path =".group.SelectDealers"> <form name ="dealerSelectionForm" type ="x.y.z.webui.GroupRenderer" method ="loadUserPreferredDealers" scope ="request"/> </render>
<!-- render a page that doesn't need forms --> <render path =".group.SelectDealers" type ="x.y.z.webui.GroupRenderer" method ="prepareSelectDealers"/>
Remember that I offered these as simply an example of how we are doing something like this in an application here -- at the moment I'm not too hot on adding a whole new config element (render), but let's see what we need.
Just to clarify, I think this is the form that your variant syntax would take:
<render path =".group.SelectDealers"
type ="x.y.z.webui.GroupRenderer"
method ="loadUserPreferredDealers">
<form
name ="dealerSelectionForm"
scope ="request"/>
</render>(The type and method are relevant to the renderer, not the form.) This would support multiple forms per render config, but if you could simply have multiple render configs, you might not need that. Our existing solution supports a list of render configs.
My preference now would be to try to extend the "forward" element rather than add a new "render" element, since I think logically they will always march together. One problem with providing multiple forms to any small chunk of code would be "how does the chunk know which form to use?" Having only one solves the problem!
However, while you can simply postulate that a single view/response can have multiple renderers or commands, it can only have one forward. So if we try to hook this to the forward element, we have to handle multiple forms some other way.
Now, if we gave the ViewContext object the ability to look up a form based on its name and scope, then we could simply let those two configuration parameters pass to a chain command, and if you had two forms, you'd put two commands in your preprocessing chain. This seems kind of promising, and it minimizes the changes we have to make to the ForwardConfig (which is also nice because the ForwardConfig doesn't go out into the wild, so any changes we make to it have to be passed along to the ActionForward which is constructed based upon it, which is one more step compared to ActionConfigs, which are passed directly in to the executing action (as ActionMappings).
Making this an interaction between each command and the ViewContext is nice, because then you really could reuse the form-prep command in multiple chains with minimal reconfiguration. We could even provide a base implementation of this class which had a getForm(Context) method.
Now, one thing is that I would like for ViewContext (and ActionContext) to have no dependencies on the Servlet API. We can make subclasses which expose those when necessary, but by avoiding them, we help continue to set ourselves up for more general uses. If we say this, then I wonder whether there's any issue in passing in the "scope". Since it's only a string, I'd say not, since we can imagine that other execution environments would also have scopes, particularly a distinction between "request" and "session", and in any case, if they are only strings, then we're not really binding to the Servlet API.
I'm liking the way this is unfolding...
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]
