On Sat, 6 Oct 2001, Ovidiu Predescu wrote: > On Sat, 06 Oct 2001 14:24:05 +0200, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > > > Peter Royal wrote: > > > > > One new feature i'd love to see is the construction of dynamic pipelines. I > > > have a hack for this in my own code right now as a transformer which > > > creates its own mini-pipeline inside of itself. > > > > Even if runtime sitemap tree travesal will make easier to implement > > this, I keep on being against such an approach even if I had the > > temptation myself to use something equivalent. > > > > The reason: it breaks separation of concerns because the sitemap > > administrator and the programmers that generates the code that generates > > the dynamic pipeline must be the same person or must overlap completely. > > > > Also, I've never seen a case where the need for dynamically generated > > pipelines could not be solved with more carefully designed static > > pipelines. > > > > However, if you have any example that proves me wrong, I'll be happy to > > reconsider my position. > > This would probably be needed when Cocoon is used in non-traditional > ways. One can use Cocoon to transform arbitrary SOAP messages > (e.g. Cocoon IS the SOAP server), where the decision of how the > pipelines look like is not known until at runtime.
Well, as Stefano pointed out I've never seen the need for it. We have an application that has Cocoon acting as a SOAP server. And we never encountered the need for dynamically generated pipelines. In contrary the pipeline remains almost the same for every request. But this highly depends on how Cocoon is acting as such a non-traditional server. > Now one can start thinking of all the possible combinations of > pipeline components, and put them in the static sitemap. But this > would make the sitemap look very ugly, and maybe difficult to pass > SOAP documents between pipelines. I think here is the point! Generally passing SOAP documents between pipelines isn't a thing we thought is practical. We instead pass normal java objects processed by actions representing the service (or dispached by it to components representing a service) to a pipeline which makes a SOAP response out of it. This has (at least for us) the benefit using "not so advanced and skilled" java programmers do a job in the web service busines as well ;). I've seen Berin evangelize the Axis community to use Avalon CM which I'd like to see (I'm a totally Avalonist and all our projects are based upon CM with Avalon because of the development speed we've gained using it). It would make an integration into Cocoon very easy (well, this is a guess). But they still are very resistent against :) Using the Transformer approach for a web service makes it too much bound to Cocoon (I know we have people here which like the custom Transformer approach very well ;). I see at least 80% of all SOAP services dealing with very little data on the request side and thus it is practical to build a usual java object out of it. Size is different on the response side but not that one need a dynamically build pipeline. For the other 20% an approach spitting SAX events directly from the SOAP document can make sense. > Besides, it would be nice to have this ability for completeness, for > the beauty of the architecture ;-). Or FS ;) Giacomo (which is now way off of the original issue of this thread :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
