Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <4687F82A.6030402@apache.org>
Date: Sun, 01 Jul 2007 20:53:30 +0200
From: Grzegorz Kossakowski <gkossakowski@apache.org>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: cocoon 2.2 - some more questions
References: <11382520.post@talk.nabble.com> <4687C798.3010607@apache.org>
 <11382998.post@talk.nabble.com> <4687D1BC.1070802@apache.org>
 <11383411.post@talk.nabble.com> <4687E4FA.8060103@apache.org>
 <11384177.post@talk.nabble.com>
In-Reply-To: <11384177.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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/