Proposed xml schema example for wiring.xml

<blocks xmlns="http://apache.org/cocoon/blocks/wiring/1.0">

  <block id="http://mycompany.com/webmail/1.3.43" 
         location="WEB-INF/blocks/384938958499">
    <mount>/mail/</mount>
    <connections>
      <connection 
        name="external-skin">http://yetanothercompany.com/skins/fancy/1.2.2</connection>
      <connection
        name="internal-skin">http://mycompany.com/skins/corporate/34.3.345</connection>
      <connection
        name="repository">http://mycompany.com/repositories/email/exchange/3.2.1</connection>
    </connections>
    <parameters>
      <param name="user">guest</param>
      <param name="password">sj3u493</param>
    </parameters>
  </block>

  <block id="http://mycompany.com/repositories/email/exchange/3.2.1" 
         location="WEB-INF/blocks/394781274834">
    <parameters>
      <param name="host">mail.blah.org</param>
    </parameters>
  </block>

  <block id="http://yetanothercompany.com/skins/fancy/1.2.2" 
         location="WEB-INF/blocks/947384127832"/>

  <block id="http://mycompany.com/skins/corporate/34.3.345" 
         location="WEB-INF/blocks/746394782637"/>

</blocks>

NOTE: if the location path of the block is relative, it is searched by starting from the cocoon war context. The block content is *always*
extracted from the archives and saves "as is" inside the folder.

NOTE (development time): in order to simplify block creation and development, it will be possible to explicity indicate the location of an already existing and extracted block implementation on disk. The block manager should also have autoreloading features (configurable, of course) that should reload the configurations, the wiring and the exposed components when they are changed.

  • No labels