cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: cocoon 2.2 - some more questions
Date Sun, 01 Jul 2007 18:53:30 GMT
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/

Mime
View raw message