cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Cocoon Blocks
Date Mon, 01 Jul 2002 21:38:49 GMT
Stefano Mazzocchi wrote:

>Sylvain Wallez wrote:
>  
>
>>Stefano Mazzocchi wrote:
>>

<snip/>

>>Why should COBs be downloaded from a remote location ? Do you really
>>think people will allow remote code to run on their production servers ?
>>    
>>
>
>No, not remote code, but packages downloaded from remote locations (like
>anybody has always been doing!).
>
>Think about it: you have apt-get, red-hat rpm updating, ximian
>red-carpet, FreeBSD ports, Windows Update, Ecplise update manager, JEdit
>plugins... just to name a few.
>
>I don't think nobody will ever mess with a production environment, but
>during development, one might want to update the blocks used to the
>latest bugfix releases, or even decide to use another implementation
>(here is where polymorphism kicks in) of the block used before, because
>it has, say, better performance or implements new features.
>
>Blocks will not only make it easier to deploy stuff on a production
>environment, but also on development.
>  
>

Ok, I understand now.

<snip/>

>>It seems to me block mounting is in fact the configuration of a "root"
>>Processor component (the interface implemented by the sitemap) that
>>performs first-level dispatching between mounted blocks. This allows to
>>keep unchanged the architecture that exists today.
>>    
>>
>
>I really don't know: I didn't want any technical details to constraint
>the design, so I didn't really look at how to implement it. But I'm
>pretty confident that it won't be hard to do given the current and very
>flexible architecture.
>  
>

Ok.

>>Now I don't think all blocks should be mounted on an
>>externally-available URI : some blocks will provide only services to
>>other blocks and no external service. The sitemap for such blocks is
>>likely to contain only internal-only="true" pipelines, but then why
>>should we have to mount them on an external URI ?
>>    
>>
>
>Good point. In that case, we might add another flag to the block
>descriptor to indicate whether or not the sitemap should be mounted on a
>URI space available to the outside. 
>

An additional question related to external mount points : how do your 
envision them to be defined ? Will it like in web.xml or through a sitemap ?

>>>For example, the forrest.cob/sitemap.xmap file could contain a global
>>>matcher which works like this:
>>>
>>>  <map:match pattern="**/*.html">
>>>   <map:aggregate element="site">
>>>    <map:part src="cocoon:/{1}/book-{1}/{2}.xml"/>
>>>    <map:part src="cocoon:/{1}/tab-{1}/{2}.xml"/>
>>>    <map:part src="cocoon:/body-{1}/{2}.xml" label="content"/>
>>>   </map:aggregate>
>>>   <map:transform src="block:skin:/stylesheets/site2xhtml.xslt"/>
>>>   <map:serialize/>
>>>  </map:match>
>>>
>>>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).
>>    
>>
>
>Great point, Sylvain. I must admit I like your suggestion of forcing
>blocks to expose their capabilities via a URI space mapping, decoupling
>it from actual implementation makes perfect sense.
>
>I agree, accessing resources directly mixes concerns.
> 
>  
>
>>So what about something like :
>>    ...
>>  </map:aggregate>
>>  <map:call resource="block:skin:/site2xhtml"/>
>></map:match>
>>    
>>
>
>Hmmm...
> 
>  
>
>>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.
>>    
>>
>
>This is absolutely true, I agree, but this requires more thinking on the
>sitemap semantics (see below).
>

I reused the current syntax for calling resources, but another one can 
be used. The important issue here is that we can have a pipeline defined 
across several sitemaps or blocks, which isn't possible today.

<snip/>

>>Will it be possible to have several blocks fulfilling the same contract
>>in a single Cocoon instance?
>>    
>>
>
>Absolutely! Since all contact between blocks is performed at the
>behavior level, it's Cocoon that knows what behavior instance is
>connected to each block. In fact, during update, I think it will be wise
>to make Cocoon keep an instance of the previous version of the block, so
>that if something weird happens, you can always go back to the previous
>version.
>
>  
>
>>For example, a site could use different
>>skins depending on the user agent or depending on the location of the
>>client (intranet / internet).
>>    
>>
>
>*NO*! that will definately break the elegance of the system! It should
>be the skin's concern to *know* how to skin the site.
>
>So, just like we are debating over at avalon-dev, you should *not* be
>using 'hints' for block lookup since you should *not* be knowing
>anything about the block you are depending from, except its behavior.
>  
>

Ok. I understand your concerns. So what about, for this particular case, 
having 3 skins : a "super-skin" that's the one used by other blocks, 
that dispatches to concrete skins depending on the environment ?

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




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


Mime
View raw message