> From: Boscoe [mailto:[EMAIL PROTECTED]] > > Vadim, > > after a few hours of sleep and a good meal, I will try to outline > my thoughts a bit more precisely. > > >As I asked above, it's unclear why do you want to use specifically XSP > >here. It's one of the possibilities, yes, but in this case it might be > >not the best one. > > 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. > 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. > 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). > > > >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. > 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]>
