Hi Grzegorz and Reinhard,
Reinhard Pötz schrieb:
[…]
There is an "abstract" block called "document-type" (think of a
document type for a CMS, actually it's about Lenya). This block
declares (in the sense of a convention) particular services,
without actually implementing them, e.g.
[…]
In my opinion SSF does not suit your job. I see blocks + SSF as a
powerful way to structure your application. SSF's capabilities allow
you to extend application's logic.
[…]
I agree with Grzegorz, this use case shouldn't be covered by the SSF.
I thought a bit more about this, and I'd like to know your opinion about
another aspect of the document types.
Basically, a document type defines a schema and a set of "formats", i.e.
options to render the documents belonging to this type. E.g., the
"docbook" document type could be rendered in the formats "xhtml",
"xsl-fo", "pdf", "txt", "xhtml-summary", "xhtml-toc", etc.
At a first glance this aspect could be handled very well by the
servlet-service framework (assuming there is a document:/ protocol to
fetch the document source from the repository, and a document input
module to retrieve information about a document):
<map:match pattern="*.pdf">
<map:generate src="document:/{1}"/>
<map:serialize type="servletService">
<map:parameter name="service"
value="servlet:{document:{1}:type}:/service/formats/pdf"/>
</map:serialize>
</map:match>
We can't use generic service blocks (e.g. for PDF rendering), because
the processing stages (stylesheets, link rewriting, i18n, …) depend very
much on the actual document type. Up to now Lenya uses its own module
mechanism for this purpose, but it doesn't provide the nice
encapsulation like the block concept, and it can only be called via the
cocoon:/ protocol, i.e. only from a generation step (nothing like
<map:serialize type="servletService"/> is possible).
Is there a clean and elegant way to do this with Cocoon 2.2?
TIA for any hints!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
