Vadim, first of all, thank you for your reply.
>>My understanding of Cocoon's XSP is that it is, roughly speaking, a >>better substitute for JSP. Due to its integration with XSLT, it is >> >> >much > > >>more flexible than JSP, but, in principal, it serves the same purpose: >>offering the developer a tool to create highly dynamic web pages. >> >> > >... to create dynamic XML content. You can then format this content and >present as web page, or generate XHTML, so no transformation is >necessary, but XSP are more generic then web pages. > > > I agree, of course. > > >>That is exactly what I need for my application which is database and >>business logic centric. Particularly in the prototyping phase, it can >>help to react very quickly to changes in the web page design. >> >> > >If you to mix design and content (and logic) in XSP, it is not wise >decision long-term. It's better to separate design into, say, XSLT >transformation, and leave XSP to generate pure data only. > > > Again, I agree. > > >>So, the >>main reason for me to use Cocoon *is* XSP. Otherwise, I would use JSP. >> >> > >Except XSPs, Cocoon offers lots of other stuff. In your case, you could >use RequestGenerator + SQLTransformer (if you use input XML in >conjunction with database). Or, you can use combination of XSP (+ESQL >for DB), aggregations (combine pipelines together), inclusions (include >output of one pipeline into another), etc. > > > > >>Next, as I said, my request data (I am avoiding the term "parameters" >> >> >in > > >>order to not confuse it with HTML form parameters) can be deeply >>structured. Therefore, I decided to send them as a XML document. >> >> > >It's logical to do so. > > > > >>If I had to use JSP, this were no problem since a JSP gives full >> >> >access > > >>to all data of a HTTP request, including the input stream. I could >> >> >read > > >>my XML document containing the request data from the input stream and >>convert it to whatever representation I want. >> >>I found out that, inside a XSP, a request object is available. But, >> >> >this > > >>object does *not* represent the HttpRequest. Instead, it is an >> >> >instance > > >>of org.apache.cocoon.environment.Request which doesn't support a >> >> >method > > >>to directly access the input stream. >> >>You mentioned earlier "inclusion". Is this a pattern to do what I want >> >> >? > >See Sitemap aggregation samples (map:aggregate), see aggregate.xsp >sample (cinclude:include), and study other sample sitemaps. See how >CInclude and XInclude transformers work. There is documentation >available on apache.org site, check out also Cocoon's Wiki at >http://outerthought.net/wiki/Wiki.jsp?page=Main. See also util >logicsheet docs (and search archive). > > > I'm a bit under pressure, but, from what I saw, map:aggregate is used to construct a XML tree from XML fragments. Not useful in my case. The first thing I have to do is evaluating my request data. They will control how the the whole request processing will proceed. > > >> > >> >As for solution (XSP + RequestGenerator), it is outlined above. >> > >> >>Can you explain that further ? >> >> > >There are multiple ways: > >1. Have two pipelines, one with XSP and second with RequestGenerator, >then map:aggregate them together, XSLT as necessary, and serve it >HTMLed. > >2. Have XSP including other pipeline with RequestGenerator with the help >of util logicsheet (documented, and also frequently asked/answered on >this list), then resulting XSP you could XSLT transform, and serve as >HTML or whatever you want. > >3. Mix in some XSLT/SQL/LDAP transformations to 1 or 2, or combine them >all together. > > > All interesting solutions, but none of them will make the XML request data available to further processing. Why isn't > > >>As I am new to Cocoon, I like to learn as much about its concepts and >>features as possible. Also, I plan to delve into the documentation >>which, btw, seems to me at the moment a bit confusing. >> >> > >Any suggestion in regards of documentation are very welcome, because >only newbies can tell which pieces are confusing, and what has not been >documented well enough. > >You can send your wishes regarding documentation to cocoon-doc list or >reflect them at http://outerthought.net/wiki/Wiki.jsp?page=Wishlist > > >Vadim > > > > >>Any suggestions are very appreciated ! >> >>TIA >> >>Boscoe >> >> > > >--------------------------------------------------------------------- >Please check that your question has not already been answered in the >FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > >To unsubscribe, e-mail: <[EMAIL PROTECTED]> >For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
