Jakob Praher wrote:
hi,AFAIK there will be no system to standardize on this, as there isn't in Cocoon now. In Cocoon you are perfectly able to assemble pipelines that do not give meaningful results, like trying to transform with a docbook stylesheet to html a Forrest document11DTD stlesheet.
I was reading through the
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
wiki page, which is a very interesting read.
There are some questions which have come to my mind:
I) One of the things that interests me, is how you want to manage
specifications of xslts?
You have to ensure that the blocks stylesheets adhere to the
specification, this means:
- the resulting data should have the right data format [xml,txt,pdf,...]
- the paths for refereing to the stylesheets must be standardized
otherwise it is useless to do:
<map:transform
src="block:skin:/stylesheets/document2html.xslt"/>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
must be standardized.
perhaps some lint like checker is needed for doing the above.
It's up to the "public API" of he block to specify these things.
Probably we will come up to a system that validates (optionally) inputs and outputs and sees that they match, but AFAIK it will be a RFE.
Some form of inheritance is planned though, so blocks should be able to extend other blocks, thus possibly implementing th esame contract (ie a skin implementation block will work as a skin block).
II) Do you see xslt reuse only at a black box model (this is the natural wayUse of blocks from other blocks is planned, but without mandating anything that must be supported by default.
for cocoon, since it deals with tranformations) .
Should there be a support for importing stylesheets from other blocks,
which means that there should be an xslt specification to define some
templates which must be supported .
(this is propably an overkill)
III) What are the problems with the current container in detail?Well, Cocoon has worked quite some time with ECM, the point is that ECM is not made to play with a block-like concept, as you say. This is the main architectural reason why it will change in the future.
I have used avalon in my own applications and like it very much, and I
would like to see a more detailed description, of what the problems of
the current ECM Containers are.
[ I think one of the problems is the static behaviour of configuration,
and classloading difficulties that come along, but maybe you can tell me
more about that here ]
It would be great if we could brainstorm on this using theASAP ;-)
wiki.cocoondev.org site.
IV) What time frame do you have for implementing cocoon blocks?
We are going in "baby steps", you are welcome to help in either or both code and discussion :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
