Gianuco, let me explain the reasons for our sitemap design choices. 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. That would be what the "internal" matcher would do: get an XML string, convert and generate HTML. 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. 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. best regards antonio signore --- Gianugo Rabellino <[EMAIL PROTECTED]> wrote: > CLEMENTE,GRAZIA (HP-Italy,ex1) wrote: > > > Thanks for your response! > > > > Can you suggest me, please, one of the alternative > way supported by cocoon > > protocol to read cocoon:/ pipelines with a > serialized output? > > Well, first of all you have to explain me why you'd > want to do that. :-) > > Serialized output is, by definition, not guaranteed > to be XML anymore: > imagine that you're trying to read something that > ends with a fo2pdf > serializer, you would be injecting PDF inside > context that expect SAX > events. So, this is a no-no, there is no way (on > purpose) to do that. > > But what, from your sitemap, seems to me that you > want to achieve is > "aliasing" a resource: what gets generated via the > match "wifi/internal" > should be the same result you get when you ask for > "wifi/prova". There > are a number of ways of doing it: the cleanest one > to me would be using > the regexp matcher so that both resources are > handled by the same pipeline: > > <map:match type="regexp" > pattern="wifi/(prova|internal)"> > > Second option is redirect: > > <map:match pattern="wifi/prova"> > <map:redirect-to uri="wifi/internal/> > > A third option is using resources (even though they > weren't exactly > designed to do that, so we're entering the hacky > way): > > <map:resource name="bla"> > [generate/transform/serialize] > </map:resource> > > [...] > > <map:match pattern="wifi/prova"> > <map:call resource="bla"/> > > > <map:match pattern="wifi/internal"> > <map:call resource="bla"/> > > ... not to mention the hackiest way ever: > > <map:match pattern="wifi/prova"> > <map:read > src="http://localhost:8888/wifi/internal"/> > > (but don't quote me on this one :-)) > > If this is not enough, well, I guess I'll need some > more background on > what you're trying to achieve and why. > > HTH, > > -- > 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/) __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
