xweber pisze:
wow - i am glad to know my crystalball is still working ;-)
;)
Most of the infrastructure is already there (especially configuration,
building and packaging parts).
building and packaging via maven?
Yes.
I have discovered that ones (thanks to the
tutorial steps)
configuration? well - you mean the pom.xml things?
No, no. We have fairy powerful Spring configurator module, see:
http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/g1/1304.html
and info about new features (that are not documented yet):
http://thread.gmane.org/gmane.text.xml.cocoon.devel/70670
Thanks to Carsten's work you can configure almost everything using properties. This way you can get a block packaged as JAR and customize
its component definitions and dependencies very heavily. I guess it covers all configuration needs.
The only part still
under development is wiring (servlet-service-fw). With blocks polymorphism
(see COCOON-2038 issue) and postable source (see COCOON-2046) you
will get all needed tools to handle even more sophisticated set-ups.
polymorphism would be nice for the database implementation of the concrete
drivers (backend).
That kind of polymorphism is achieved with Spring and configurator mechanism. For example, you can always configure a concrete class to use
other DB provider (also a Spring component) that you have implemented.
For wiring beyond spring block i thought i could use
something like "inner piplelines".
We have had a concept of internal requests for years in Cocoon. What
servlet-service-fw brings new is something like that:
<map:generate src="page-template"/>
[some transformations]
<map:serialize type="servletService">
<map:paramter name="service"
value="servlet:styling-block:/service/transformToHtml"/>
</map:serialize>
You define "styling-block" as block's connection, and have in styling-block you
have:
<map:match pattern="service/transformToHtml">
<map:generate src="service-consumer:">
<map:transform src="some-styling.xsl"/>
<map:serialize type="html"/>
</map:match>
Ok, it's nice because you can have one block that is responsible for styling but it's not the end of story. Polymorphism begins when you
create a third block, let's call it "fancy-styling-block", and declare that "styling-block" is its super block.
Now, thanks to properties, you can change connection declared in first block, so it connects to "fancy-styling-block" instead of
"styling-block". Next you define in "fancy-styling-block" another matcher:
<map:match pattern="service/transformToHtml">
<map:generate src="service-consumer:">
<map:transform src="some-fancy-styling.xsl"/>
<map:serialize type="html"/>
</map:match>
This way you _override_ pipeline from "styling-block". Of course, you can override only a few pipelines you want to customize and leave rest
untouched.
This way you get very powerful mechanism for extending your blocks.
yes, there are a lot of question (which is still first try to figure out
myself).
But here is one:
rcl.properties reads like:
com.mycompany.myBlock2.block%classes-dir=../myBlock2/target/classes
%exclude-lib=com.mycompany:myBlock2
ok, i can guess the first line - but why (and when) to exclude libs? The doc
http://cocoon.zones.apache.org/daisy/cdocs/g1/g5/g1/g1/1298.html does not
give that much detailed information yet
I'm not sure (I hope that Reinhard will comment) but I think that you include classes compiled by your IDE (first line) and thus you must
exclude classes from JAR of block2. If we didn't do this, we would have every class in classpath present twice.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
