On Thu, 17 Mar 2005 06:33:42 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > For the record: Since what I wanted looked more like a Command, I > dropped the extension to CreateAction. Instead, I wired Spring to > produce instances of DispatchCommand (in the commons-chain SVN repo), > and I wrote a pair of commands: one which copies any bean out of the > Spring ApplicationContext into the Chain Context,
I'm thinking there's something to that "minds think alike" chestnut ... I'm doing something similar myself now in ar ASPX/Mono application that uses a CoR port. We put "untrusted" values into an input context (a bit like an ActionForm). A "standard" Command validates and converts values into the "main" context, where other Commands can use them. On the way back, there is another Command that copies values from the main content to the input buffer, formatting the values as needed. The Commands refer to a "FieldTable" (configured through Spring) that specifies the target DataType, alert message, and so forth, so that these shared facts can specified in an XML document, as we do with the Struts Validator. What I really like about this strategy is that it centralizes validation, conversion, and formatting. > and another which > extends LookupCommand to get its command out of the Context instead > of by looking in a catalog. And again ... on our code-behinds (or "backing beans"), the event handlers call an application controller to acquire a Context to fill with values and then submit back to the Controller for processing. The Controller actually acquires the Command first, and then puts a reference in the Context to use later. When ready, the handlers ask the Controller to "execute" the Context. Of course, what the Controller does is pull the Command reference back out of the Context, and execute the Command. The end result is a compact idiom that goes something like: INexusContext context = Controller.GetContext(App.COUNTY_LIST); context[App.COUNTY_KEY] = CountyKeyList.SelectedValue; Controller.Execute(context); if (context.IsNominal()) ... display list found in context ... else ... display messages found in context ... This example is simplified in that we have methods that automatically harvest the values from controls, so a more typical example would be: INexusContext context = Controller.GetContext(App.COUNTY_LIST); ReadControls(controls, context); Controller.Execute(context); ... Utilities like ReadControls work well for us because we name controls after their corresponding context identifier, a la Struts. (Thanks for the fish!) It's interesting to note that ASPX uses the same "correspondence" strategy as Struts. The member names on the code behind correspond to controls names in the server page, just like property names of an ActionForm correspond to field names of the custom tags. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
