Quoting "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>: [snip] > > > > Although it's not evident from the Jericho DTD, the intention > > is to use > > a Context object in the signatures, perhaps the Commons Chain > > Context, > > so as to encapsulate Servlet/Portlet dependencies. > > > > So you no longer going to pass in request and response objects > around, but instead have a context instead. Maybe it would > be a little inconvenient for every Action to call > ``context.getRequest()'' all the time. Perhaps we can keep them > please. I dont mind losing the form bean. I could live with > ``context.getForm()'', because for some environments you dont > need to buffer a user's input. e.g. web services, or even > a flat file. > > public ActionForward someStateAction( > org.apache.commons.chain.Context context, > some.generic.request request, > some.generic.response response ); > > And for those of us who have subclassed Action, and ActionForm > to create our own super frameworks, this will be very > interesting and involved work to say the least/. >
If you're going to call context.getRequest() at all, then I think you're losing most of the benefits of abstracting away the servlet APIs - if you want to be able to reuse "actions" in the business tier then there *is* no such thing as a request. Instead, it would be better for a particular Command (for purposes of this discussion, I'm assuming we use something like commons-chain as the plumbing so I use that terminology; it would need to be translated for a different low level API but the concepts sare still the same) that represents the concept of an "action" to presume that some previous commands in the chain have already pulled the presentation tier specific data out of whatever "request" objects there were, and made it available as context attributes of the appropriate (framework-specific) types. For example, assume we created an abstraction of a form (what is now ActionForm) to represent incoming data from the user. Copying request parameters into this abstract form thingie would be the job of a command very early in the chain. It's easy to imagine at least three commonly used lead-in actions: * One that pulls request parameters from an HttpServletRequest (servlet api) * One that pulls request parameters from a PortletRequest (portlet api) * One that pulls request parameters from a SOAP request The key value-add is that, once the lead-in command has performed this transition for you, no further commands ever need to know that there *was* such a thing as a "request". Those commands would never call getRequest(), because they don't care how the "form thingie" got there; it contains everything they need to perform their tasks. Therefore, you can reuse the processing command in new and interesting ways -- just to whet the appetite, consider: * In a unit test, where the test case synthesizes a "form thingie" with known contents, calls the processing logic, and ensures that the correct state changes happened. No real "request" ever exists. * In an integration app, where you want to have changes made in an existing application also affect data in a separate app. One way to do that would be to synthesize more than one "form" from the same actual user input, and do all the necessary updates. The business logic for any single transaction has no need to know that it's being used in this new way. * In a batch application (or a messaging appication, or ...) where the incoming data is acquired from data files rather than users, but you want the same sorts of state changes in your back-end systems. The hard part (in terms of designing the framework) is to understand how to factor the reusable concepts, and then what to name them -- on that topic, for example, even the name "form thingie" might be a little bit to constraining when imagining how the basic idea can be used in more than one context. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
