cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sat, 13 Sep 2003 19:06:10 GMT
Stefano Mazzocchi wrote:
> On Friday, Aug 29, 2003, at 05:53 Europe/Rome, Geoff Howard wrote:
>> Wiki'd here:
>> For sake of discussion, I recorded a wire-id instead of the location.  
>> Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} > ?
> potentially, yes. Sylvain suggested that, during block development, you  
> might want to keep the block in the directory you are used to and have  
> cocoon point to that, instead of having to copy it there everytime.
> so, you need to add a block/@location attribute (preferred over an  
> element, because a block can have one and only one location)

Ok, I've udated the wiki to use @location (as proposed above, not as 
written below with <location>


> <blocks xmlns="">
>  <block id="">
>   <location>WEB-INF/blocks/384938958499</location>
>   <mount>/mail/</mount>
>   <connections>
>    <connection  
> name="external-skin"></ 
> connection
>    <connection  
> name="internal-skin"></ 
> connection>
>    <connection  
> name="repository"></ 
> connection>
>   </connections>
>   <configurations>
>    <param name="user">guest</param>
>    <param name="password">sj3u493</param>
>   </configurations>
>  </block>
>  <block id="">
>   <location>WEB-INF/blocks/394781274834</location>
>   <configurations>
>    <param name="host"></param>
>   </configuration>
>  </block>
>  <block id="">
>   <location>WEB-INF/blocks/947384127832</location>
>  </block>
>  <block">
>   <location>WEB-INF/blocks/746394782637</location>
>  </block>
> </blocks>
> Rationale for this:
>  1) there could be many blocks
>  2) there can be only one block with the give URI in the system (so the  
> use of '@id' is meaningful also from an XML perspective)

Ok, changed name to @id.

>  3) the wire-id number is not semantically meaningful from a block  
> perspective, it's simply autogenerated by the deployment tool, but  
> location can be arbitrary and block URI are already uniquely  
> idenfitying the block

Gotcha.  wire-id is gone.

>  4) changed "configuration" in "configurations" to identify a container  
> that can contain one or more parameters.

I took the liberty of changing this from configurations to parameters 
since in my mind configuration already refers to a group of settings but 
we want to keep the plural explicit.  Also, parameter better indicates 
the key-value expectation whereas configuration(s) may imply the 
possibility of deeper nested items.

>> <connection> was out of the blue using the wiring metaphore.  Other  
>> options?  Free association: connect, attach, solder, wire, use ...
> I have no problems with this.
>> Is it wise to limit configurations to name-value pairs, or should 
>> that  allow arbitrary foreign xml markup?
> No, name-value pairs is fine. Everything else would be too hard to  
> configure at runtime and block shouldn't need too many parameters for  
> configuration at deployment time.
>> For configuration, should a distinction be made between any  
>> create-time values and deploy-time values, or is that pointless once  
>> the wiring has happened?
> that section will only contain deploy-time values. create-time values  
> will be included in the block.xconf, which is the block equivalent of  
> cocoon.xconf (and will be full xml configurations)

Ok, gotcha.

>> For the wiring connections: should the matching uri even be recorded  
>> here, or only the role its looking for? (I think the uri, but just  
>> tossing out questions).
> yes, both name and URI are required to fully identify the wiring.
>> What blocks version is this?  1.0? 1.1? 2.1? 2.2?
> Following namespace URI versioning conventions, I would say "1.0" since  
> it's the first release of such a schema.

Wiki updated to reflect the current state.  I'll start on cob.xml if no 
one beats me to it.


View raw message