cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject [RT] Component manager, classloader and blocks
Date Fri, 10 Oct 2003 11:22:20 GMT
Hi,

Since some days I thought about how implement blocks with smallest
amount of work. (small ist beautiful)

Most of the work is already finished, if we look into the 'unreal'
block in the CVS repository. We have
a classes, libs, a sitemap, a xconf file and some custom files.
We could easily pack them into a zip file.

What need:

For every block we need
* a block URI, which identifies it.
* statements about dependecies to other blocks.
* Component manager, for a separate cocoon.xconf
* Sitemap proccessor for the root sitemap of the block
* A classloader for each block, which were exchange if the
  the block has changed.

The simplest form to include the information about the block
URI and the dependencies is to use the sitemap for it, for example

<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
 <map:block uri="http://apache.org/cocoon/block/myblock/1.0">
  <map:import block="basic" uri="http://apache.org/cocoon/block/basic/1.0"/>
 </map:block>

For the sitemap components we need two component manager for
handling the 'public' and 'private' components.

 +---------------+        +---------------+
 | myblock       |        | basic         |
 | +-----------+ | lookup | +-----------+ |
 | | public cm |-+--------+>| public cm | |
 | +-----------+ |        | +-----------+ |
 |      ^        |        |      ^        |
 |      | lookup |        |      | lookup |
 |      |        |        |      |        |
 | +-----------+ |        | +-----------+ |
 | | private cm| |        | | private cm| |
 | +-----------+ |        | +-----------+ |
 |      ^        |        |      ^        |
 |      | lookup |        |      | lookup |
 |      |        |        |      |        |
 | +----------+  |        | +-----------+ |
 | | sitemap  |  |        | | sitemap   | |
 | +----------+  |        | +-----------+ |
 |               |        |               |
 +---------------+        +---------------+

Another difficult part is about the dependecies of the CMs between
subsitemaps (I doesn't have a solution). I think subsitemaps
are a contrary solution to blocks, perhaps we should rethink the
subsitemaps.

To prevent component name collisions within, we could use prefixes like

 <match type="basic:wildcard" pattern="*.html"
  <map:generate type="basic:file" src="{1}.xml"/>
  <map:transform type="basic:xsl" src="mystyles.xsl"/>
  <map:transform type="mytransformer"/>
  <map:serialze type="basic:html"/>

If there is no name collision, you can leave out the prefix.
The problem is that the current CM model doesn't support
such a kind of prefix, but it doesn't need to, because
the sitemap processor can resolve the prefix, and know
which CM to ask for.


For the classes and libs itself, I think separate them into public
and private isn't necessary for the first step.
A cheap solution is use following FS within a zip file:

myblock.zip
 /COB_INF/classes
 /COB-INF/lib
 /COB-INF/componts.xconf
 /sitemap.xmap
 /[whatever]

Every block get his own classloader, and if the block has changes
the classloader will be exchanged. Each depending block has
a parent classloader, which will be consulted if the current
classloader doesn't know the class.


My unsorted braindump, Stephan.

> cat /dev/brain | grep "blocks" | mail dev@cocoon.apache.org

_______________________________________________________________________
         Stephan Michels               EMail: stephan@apache.org
         ICQ: 115535699                Tel: +49-030-314-21583
----+----|----+----|----+----|----+----|----+----|----+----|----+----|-|



Mime
View raw message