cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Component declaration and lookup
Date Wed, 24 Nov 2004 07:26:32 GMT
Sylvain Wallez wrote:

<snip/>
> What I don't like currently is that a lot of blocks use the xconfpatch 
> task to insert their own stuff in the root sitemap. IMO this is bad, 

Yes, this is a hack :-(

> and 
> block-specific components should only be present in block-specific 
> sitemaps. That's a first step towards reduction.
> 
> Now, about the WEB-INF/sitemap.xmap: this is a good idea to have some 
> "system-defined" sitemap components, but it's not properly speaking a 
> sitemap since it should define only components and no pipelines.
> 
> If you relate this to my earlier proposal of splitting the xconf file, 
> that would mean we'll have a sitemap-builtins.xconf in WEB-INF along 
> with the other xconf snippets. And the block-specific xconf files could 
> also bring not only system-level components, but also sitemap 
> components. For example, the "database" block would bring in its 
> "database-block.xconf" not only the datasources, input/output modules, 
> but also the SQLTransformer.

I like the idea of having a sitemap-buildins.xconf in WEB-INF.

                                    - o -

After your proposal of splitting up component declarations I think we should try 
to implement all things in Cocoon 2.2 that are needed for real blocks as they 
will be used in kernel.

- a block has a
   * root sitemap (well, pipelines, views, sitemap components)
   * sitemap-buildins.xconf (sitemap component declarations)
   * block.xconf (all non-sitemap component declarations)

- a BlockManager
   * access to all available blocks
   * interface for treeprocessor
   * interface for sources

- the treeprocessor mounts block root sitemaps
   * The treecprocessor has to look first into the sitemaps provided by blocks
     and then into Cocoon core sitemap - uses the BlockManager

- the "block" protocol
   * lookup sources in other blocks - uses the BlockManager

- the service maanager
   * uses the BlockManager to lookup components provided by blocks



...  and then there are a few points that are not that clear for me:

- a reusable syntax for component declaration
   * Well, the declaration of kernel components differs from the declaration
     of ECM components. Is there any chance to reuse ECM component declarations
     in kernel? Component handling is the only difference I'm aware of that
     wouldn't be backward compatible after kernel is integrated. If this is
     not possible we can't deploy 2.2 blocks in Cocoon 2.3 (assuming that
     2.3 supports classloader shielding)

- support of other component frameworks
   * Let's assume that I want to use Spring for my business components and
     I also want to make use of blocks and split my application into smaller
     parts (modularization). Most spring users use the XmlBeanFactory but this
     wouldn't be sufficient for Cocoon because our components could be spread
     over many blocks. So we would have to provide our own BeanFactory
     implementation that uses our BlockManager to resolve all dependencies.
     Am I on the right track or do we tackle this problem on another level?

- support for O/R-Mapping tools
   * Basically the same problem as described above.

- how can I use sitemap components declared in other blocks?
   * <map:generate type="myspecialblock:repositorygenertor" src="bla"/>
     --> maybe Stefano can explain his latest proposal of component lookup
         in this context again [1]

- input modules
   * I define an input module in a block. How can I access it in another block?
     Our current syntax of is not enough for this.

- sources
   * How can I access sources provided by other blocks? Again, our current
     syntax is not enough

- component lookup syntax
    * If I want to lookup a component from a different block? What's the syntax?
      something like manager.lookup("myspecialblock:repository")

- logging
   * What's the logging target of a block?

- session attributes
   * Block A adds the session attribut "XY". If block B that doesn't event know
     of the existence of block A does the same, we end in a naming collision.
     Is this a problem of the person implementing the block? It could be solved
     by him if he uses unique names like the block URI as prefix.


[1] http://archives.real-time.com/pipermail/cocoon-devel/2004-October/037922.html

-- 
Reinhard

Mime
View raw message