On Sun, 25 Nov 2001, Michael McKibben wrote: > Maybe I am missing something fundamental, but I don't see how using Cocoon > as a service violates IoC?
Well, I'm not the right person to answer this :) > Cocoon naturally provides the Processor interface > as a service. The current CocoonServlet initializes the Cocoon component and > then delegates HTTP requests to the Cocoon Processor. My goal is to move the > initialization step to a block. Then I would write a Servlet that looks up > the Processor and delegates the HTTP request ala CocoonServlet. Why do this? > Well, now I can deploy multiple wars in my Servlet container all using a > shared Cocoon component. I could even use Cocoon from a MessageDriven EJB. > This is the idea anyways. Hopefully it works in practice. If I understand you correctly, you still have a single entry-point (HTTP) and therefore I believe you don't violate IoC. > I believe the advice given to you by cocoon-dev was to not call > sub-components of Cocoon (i.e. components defined in cocoon.xconf and the > sitemap.) Of course you have to call into the Cocoon Processor, otherwise, > how would you use it! Requests have to get passed into Cocoon somehow :) My idea was to have better granularity at the service level, not just one big "Cocoon service", so every application that needs parts of Cocoon's functionality can simply get a hold of the specific blocks it needs. Going over HTTP means you need a webserver, a document repository at the webserver's location and a (potentially costly) HTTP connection every time you have a request, plus you need to go through the whole processing pipeline every time, even if you know from the start where you want to go. Instead, since my applications run under Phoenix anyway, I could use the functionality directly, if it were available in Phoenix-friendly form, e.g. as a block. Anyway, one argument in the discussion was that for such simple tasks I should write a wrapper around Xalan or fop and not use Cocoon at all, because it is meant for more complex processing. So that is the route I'm going at the moment, even though I believe my system will become more complex with time, too. Also I need Cocoon for the frontend anyway, so there's some duplication of efforts. It would be better if I could use the same Cocoon engine in my backend apps and in the browser-based frontend. Well, you're never too old to learn, so perhaps one of these days I see the light :) Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
