On Friday, Aug 29, 2003, at 05:53 Europe/Rome, Geoff Howard wrote:
Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring
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="http://apache.org/cocoon/blocks/wiring/1.0";>
<block id="cob:mycompany.com/webmail/1.3.43">
<location>WEB-INF/blocks/384938958499</location>
<mount>/mail/</mount>
<connections>
<connection name="external-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</ connection
<connection name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</ connection>
<connection name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</ connection>
</connections>
<configurations>
<param name="user">guest</param>
<param name="password">sj3u493</param>
</configurations>
</block>
<block id="cob:mycompany.com/repositories/email/exchange/3.2.1"> <location>WEB-INF/blocks/394781274834</location> <configurations> <param name="host">mail.blah.org</param> </configuration> </block>
<block id="cob:yetanothercompany.com/skins/fancy/1.2.2"> <location>WEB-INF/blocks/947384127832</location> </block>
<block id=cob:mycompany.com/skins/corporate/34.3.345"> <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.
Geoff
