On Tue, 15 Mar 2005 11:23:09 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:>Joe had mentioned wanting to move module init code to the> >ModuleConfigFactory. ... It wasn't really discussed, just mentioned. :) The point was to move the code out of ActionServlet more than to move it into ModuleConfigFactory. http://marc.theaimsgroup.com/?l=struts-dev&m=110908681127847&w=2
I wrote:
From a purely conceptual standpoint, I almost think that everything inside initModuleConfig() should be moved into the ModuleConfigFactory.
in the sense that modules are useless as pure beans, so both instantiation and configuration should be the responsibility of the factory.
>From a Struts perspective, this would be like writing an Action class and specifying in struts-config whether that Action class supports servlets, web services, JMS, or all of them or any combination of these and others. A protocol-specific object would accept requests, populate the ActionContext, then send it to a module's RequestProcessor for processing. After the request is processed, the RP sends it back to the protocol-specific object to send back the response in an appropriate way.
Or did I just venture too far from what you were trying to picture?
I think this is a good description of a general use case/"to-be-desired" scenario for Struts. As it is now, the chain commands themselves are too dependent on the Servlet API, and consideration of the case you describe might help think of solutions to that. As it is now, you'd really need an entirely different chain if you weren't using Servlet, because so many of the implementation classes are critically depending on the Servlet API. This is pragmatic, but its something we should be consciously working on fixing. But this is long term strategy. (Referring back to our"project management" discussion, maybe we should come up with some simple searchable string that we could include in emails when we talk about "long term strategy" so that we can find them easily again ;-)
Well, moving what we can from ActionServlet to ModuleConfigFactory doesn't really help testability that much right now. It's just to reduce the size of ActionServlet and move code that doesn't need to be there. It doesn't have to be the ModuleConfigFactory either, though right now, that's the best fit.
No -- but getting to a scenario where you don't really need the ModuleConfig for many operations would help testability. But if we also keep dependencies on the ModuleConfig itself to a minimum, preferring situations where elements from it are passed in as arguments,
This is how I felt about putting ActionContext in a ThreadLocal variable -- an incremental steps towards POJO Actions. :)
Yes... I'm sorry that that discussion has stalled. Although I don't even know if that's an incremental step towards a POJO action -- it's practically all you need, plus a little more smarts in the CreateAction command. I'll go post a ping.
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]
