cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: [design] Cocoon Blocks 1.1
Date Sun, 03 Nov 2002 18:40:52 GMT
1. I definitely agree with Sylvain's view of blocks as classes, not as 
instances. I think is important to expose pipelines and not individual 
resources. Sylvain explained to me why this is important when it came 
to the control flow layer, which now uses only pipelines and not 
resources.

2. Another question is how are we dealing with flow scripts? Are we 
going to expose functions on a per-block level?

<map:call function="block:user:login"/>

Or we consider flows as resources of the block, hence hidden from the 
user, and accessible only through pipelines publicly exposed?

I would favor the latter, as it's in line with the pipelines idea 
Sylvain mentioned.

3. What is the relationship between libraries defined in a block and 
those defined in the container loading it? Are they loaded by the same 
classloader or by different classloaders?

I think the latter would help isolate contracts between different 
blocks, at the risk of duplicating libraries in the runtime system.  
The impact should be minimal however in real life, with different 
blocks serving different purposes (FO generation etc.).

Coupled with the exposure of pipelines only, block contracts are then 
well defined and separated.

Regards,
-- 
Ovidiu Predescu <ovidiu@apache.org>
http://webweavertech.com/ovidiu/weblog/

On Saturday, Nov 2, 2002, at 15:08 US/Pacific, Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:
>
>>
>>                             Cocoon Blocks
>>                             -------------
>>
>>   author: Stefano Mazzocchi
>>   status: working draft
>>   version: 1.1
>>
>> (see the end of the document for changes from the previous version)
>>
>>
>> DISCLAIMER: This document must be considered as a working draft and 
>> may be updated at any time.
>
>
> OK. Let me throw in some material for version 1.2 ;-)
>
> Throughout this paper, examples show blocks providing "resources" to 
> their users (such as stylesheets of images), but the word "service" is 
> used several times to identify what is provided by a block, and IMO 
> services are more important to define a block contract than resources.
>
> Most of this was already stated after version 1.0, back in July. See 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102538716114027&w=2
>
> Here is the most relevant part :
>
> <old-post-quote>
>
>> please note the
>>
>> block:skin:/stylesheets/site2xhtml.xslt
>>
>
> IMHO, this example goes strongly against the benefits that blocks want 
> to bring. The functionnality brought by the 'skin' block is... 
> skinning. It's not an XSL stylesheet at a particular location. What if 
> someone has written the killer skin for his site, but this skin 
> requires a multi-stage pipeline that cannot be represented by a single 
> stylesheet ?
>
> The contract of a block should be services identified by their URI, 
> and not files at well-known locations (even if these 'files' are in 
> fact produced by a pipeline).
>
> So what about something like :
>    ...
>  </map:aggregate>
>  <map:call resource="block:skin:/site2xhtml"/>
> </map:match>
>
> This call "jumps" to a service provided by the block and its URI is 
> part of the block's contract. We don't care (because we don't have to) 
> if the service is implemented by an XSL or by the next-generation 
> transformer.
>
> What the "jump" does is feed a pipeline in the block with the result 
> of the current pipeline. The whole pipeline is terminated in the 
> called block.
>
> But just as a pipeline can serialize or not depending on if it's an 
> internal request or not (see SitemapSource), the same service could be 
> used as a transformation. We could then write something like :
>    ...
>  </map:aggregate>
>  <map:transform type="pipeline" src="block:skin:/site2xhtml"/>
>  <map:transform type="urlencoder"/>
>  <map:serialize/>
> </map:match>
>
> By considering blocks as pipeline services, we really achieve true 
> polymorphism for blocks, because we totally abstract the way their 
> contracts are implemented.
>
> [note that all the above isn't in fact block-specific and can be made 
> today inside a single sitemap]
>
> </old-post-quote>
>
> After this we had a long conversation about the semantics to be used 
> to identify which part of a pipeline we want the caller to use, which 
> unfortunately fell flat because I wasn't able to make you understand 
> my thoughts. I'd like someday to have the luck Carsten had recently to 
> meet you for real. Too bad the GetTogether is the same week as the 
> ApacheCon :-(
>
> Anyway, let's forget for now these syntactic problems. The important 
> thing above is that a block should provide services by means of 
> pipeline URIs and not resources.
>
> If we were to compare a block with a Java class (not so silly, since 
> blocks now have inheritance), a pipeline service would be a method and 
> a resource would be an attribute. Is it good programming practice to 
> define a class contract by its attributes ? No, and the same applies 
> to blocks, if we want their contracts to be solid enough to accept 
> various implementations.
>
> I have kept below only parts that show the use of services  :
>
> <snip/>
>
>> Improvement #1: component-oriented deployment
>> ---------------------------------------------
>>
>> Let me give you a possible use-case scenario.
>>
>> Let us suppose that we implement WAR-like package deployment on top 
>> of Cocoon and that your application requires both PDF serialization 
>> and SVG->PNG rasterization.
>>
>> Then, you implement another cocoon web application and you still 
>> require PDF generation.
>>
>> Unfortunatley, since WAR-like installation isolates the packages and 
>> their classloaders, you have to install the PDF serialization 
>> libraries twice.
>>
>> Thus the idea of blocks as units of deployable service. Here is a 
>> picture:
>
>
> So the main idea of blocks is about services. Great !
>
> <snip/>
>
>> Improvement #2: polymorphic behavior
>> ------------------------------------
>
>
> <snip/>
>
>> Here, the webapp1 requires "fo-pdf" serialization services but it 
>> does not care (nor should!) which implementation of this service is 
>> actually located into the system.
>
>
> Sure : the "fo-pdf" _service_ can be implemented by a single 
> serializer, or by some transformations preceding another serializer. 
> This clearly cannot be a resource.
>
> <snip/>
>
>> Improvement #3: block inheritance
>> ---------------------------------
>
>
> <snip/>
>
>> The best solution is to allow my block to explicitly "extend" that 
>> block and inherits the resources that it doesn't contain.
>
>
> Side note : we must not forget to allow a block to call 
> services/resources of its parent block (like a "super" call in Java).
>
> <snip/>
>
>>  +---------------------------+
>>  | Part 2: technical details |
>>  +---------------------------+
>
>
> <snip/>
>
>> Resource dereferencing
>> ----------------------
>
>
> <snip/>
>
>> For example, the myblock.cob/sitemap.xmap file could contain a global
>> matcher which works like this:
>>
>>    <map:match pattern="**/*.html">
>>     <map:generate src="{1}.xml"/>
>>     <map:transform src="block:skin:/stylesheets/document2html.xslt"/>
>>     <map:serialize/>
>>    </map:match>
>>
>> please note the
>>
>>  block:skin:/stylesheets/document2html.xslt
>
>
> Here is what triggered this idea of "pipeline services" ! This example 
> only shows publication of _resources_ (i.e. static files) by the block 
> !
>
> <snip/>
>
>> TODO
>> ----
>>
>>  1) blocks should allow to depend on 'ranges' of behavior versions. 
>> Let's try to come up with a way to describe those ranges effectively.
>
>
> IIRC, there's something in Avalon to handle this.
>
> <snip/>
>
> Ok. I hope this time this notion of "pipeline services" will go 
> further and that we will solve the misunderstanding we had 4 months 
> ago...
>
> Sylvain
>
> -- 
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message