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:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
