You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/11/24 08:26:32 UTC
Component declaration and lookup
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
Re: Component declaration and lookup
Posted by ro...@dds.nl.
Quote Peter Hunsberger <pe...@gmail.com>:
<snip/>
> >
> > - a block has a
> > * root sitemap (well, pipelines, views, sitemap components)
> > * sitemap-buildins.xconf (sitemap component declarations)
> > * block.xconf (all non-sitemap component declarations)
> >
>
> One question: why two xconf files instead of just a single file with
> two different sections? The less places I have to look for
> configuration information the better...
>
> <snip> more good details</snip>
>
I very much agree. The first thing that I thought of reading this thread is
there is a trade-off between one gigantic configuration file in which you can't
find anything, and configuration fragmented over too many files, with
interdependencies and whatnot. Maybe the structure of the configuration file
should just be deepened a couple of levels?
Rogier ( who is frustrated with having to define a single jndi datasource in a
zillion places ;)
Re: Component declaration and lookup
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Peter Hunsberger wrote:
>
>> On Wed, 24 Nov 2004 08:26:32 +0100, Reinhard Poetz
>> <re...@apache.org> wrote:
>>
>>> Sylvain Wallez wrote:
>>
>>
>>
>> <snip> introductory comments</snip>
>>
>>> 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)
>>>
>>
>>
>> One question: why two xconf files instead of just a single file with
>> two different sections? The less places I have to look for
>> configuration information the better...
>
>
> Good question. I was following Sylvain's proposal. Can't give you a
> rational reason, but I prefer a clear destinction between sitemap
> components and all other components ... (maybe I'm working too long with
> Cocoon ;-)
>
I meant *have been working* ;-) (not always that easy for German speakers)
--
Reinhard
Re: Component declaration and lookup
Posted by Reinhard Poetz <re...@apache.org>.
Peter Hunsberger wrote:
> On Wed, 24 Nov 2004 08:26:32 +0100, Reinhard Poetz <re...@apache.org> wrote:
>
>>Sylvain Wallez wrote:
>
>
> <snip> introductory comments</snip>
>
>>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)
>>
>
>
> One question: why two xconf files instead of just a single file with
> two different sections? The less places I have to look for
> configuration information the better...
Good question. I was following Sylvain's proposal. Can't give you a rational
reason, but I prefer a clear destinction between sitemap components and all
other components ... (maybe I'm working too long with Cocoon ;-)
--
Reinhard
Re: Component declaration and lookup
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 24 Nov 2004 08:26:32 +0100, Reinhard Poetz <re...@apache.org> wrote:
> Sylvain Wallez wrote:
<snip> introductory comments</snip>
>
> 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)
>
One question: why two xconf files instead of just a single file with
two different sections? The less places I have to look for
configuration information the better...
<snip> more good details</snip>
--
Peter Hunsberger