Antonio Signore wrote:

Cocoon is used on our FEs front end machines (that are
Sun Solaris) as HTML rendering engine served by Jetty.

All our business logic is instead on a clustered BE
backend machine and served by a Tomcat engine.

The FEs communicate with the BE on HTTP connections
via an XML protocol.

We designed the sitemap to have one pipeline only that
implements the connection to the BE, receives the XML
responses, transform them via XSL stylesheets and
generate HTML.

Fair enough...


That would be what the "internal" matcher would do:
get an XML string, convert and generate HTML.

Well... I wouldn't have generated HTML straight away (as in "serialized HTML"), but I see your point.


Then we have added all bunch of mathers that use such
internal matcher to deliver HTML to a variety on
clients that may require some added logic.

So you mean that some other matchers might need to _work_ on the output, e.g. by adding some different information? If this is the case, you clearly need to define a resource without a serializer, and call it in the matchers below.


All these added matchers use the single internal one.
This way we keep the sitemap the smaller as possible.


However, the map:read worked (and frankly we were
surprised it did...) but it does not work any longer.


So, we would like now to find an alternative to the
map:read without having to redesign the whole sitemap
that would be expensive in terms of time constraints.

Well, if you have serious time constraint you can use HTTP, but this will be a) hacky and b) expensive in terms of suboptimal processing time.


Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
    (Blogging at: http://www.rabellino.it/blog/)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to