Paul Hammant wrote: > > Some of us were thinking that we could write some blocks for Cocoon to > provide a generic Cocoon rendering component, but Jo! hosting the > existing thing might be a useful way of having that functionality before > a full block-ization.
Here's a paragraph I just posted to cocoon-dev: 95% of what I need is a block that does XML-->XSL(FO|T). I have many server-side apps, who would love to use this block. Why should they make a costly HTTP connection to some server that runs Cocoon and commit to the interfaces Cocoon prescribes? Wouldn't it be much cooler if I used the "XML-->XSL(FO|T)" block from Cocoon and keep everything within the framework and on the same JVM? I could even run a HTTP/Servlet server under Phoenix (e.g. Jo!) and have it use Cocoon's blocks for doing XML stuff - no costly TCP connections to some servlet engine anymore. Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
