Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
<snip/>
2.) ECM has to "ask" the BlockManager which blocks exist and include all block
specific component declarations:
/WEB-INF/blocks/4711/block.xconf /WEB-INF/blocks/4712/block.xconf ...
This is natural to do based on the current "global" block component handling in Cocoon, where all block components are included in the global cocoon.xconf. The question is if we should continue in this way or not. An alternative way would be to only include components in the sitemap where it is used (and of course its subsitemaps). In that case the block.xconf can be found by using a "block config" protocol: "blockconfig:my-block" e.g. and included in the sitemap where the block is used using Sylvain's include mechanism.
Avoiding having globaly defined components as default might be an advantage as it decreases the risk that blocks collide on the other hand it might make it somewhat more complicated to use blocks as one have to decide where to include their components. I don't know, but now with the more flexible component configuration mechanism we at least have a choice.
Sylvain and I had a discussion about this as well. Our conclusion was that the block.xconf contains markers whether a component is global or lokal.
Makes sense to make it choosable, wouldn't it be even better to make it part of the deployment descriptor?
If we don't include block components at root level as default, the ECM doesn't have to ask anything.
3.) the sitemap processor "asks" the BlockManager where the root-sitemaps of
all blocks can be found (configured in the block.xml - the main
configuration file of a block)
/WEB-INF/blocks/4711/sitemap.xmap /WEB-INF/blocks/4712/myblocksitemap.xmap
Here we have a similar question: global mount at the root level or explicit where it is used.
We could mount block sitemaps using the "map:mount" construction togeher with the block protocol. An advantage with this is that it is a natural extension on what we already have, no need for any new concepts. A disadvantage is that it is far from obvious how to implement the link transformer that transforms from the block protocol to links.
Another disadvantage: I want to deploy a block and this deployment shouldn't require a change in the root sitemap.
If we instead mount blocks at the root sitemap level, which is the current plan if I understand http://wiki.apache.org/cocoon/BlocksWiring right, we get some advantages: The link transformer will be easier to implement, maybe it will be easier to use a block sitemap as you don't need to write a sitemap rule. But there are a number of questions about what it will mean to mount a block at the root level. What will happen if one block is mounted at "/foo" and one at "/foo/bar"?
First the list of all mounted block sitemaps is gone through. The mount uri that fits best is called.
Best match semantics is IMO good as you can see in my RT.
How should it be related to the rules in the root sitemap, are the mounts in the wireing used before or after the root sitemap?
before
I think best practices will be a root sitemap without any pipeline and one block that is mounted at "/".
Sounds also reasonable. The sitemap mounting is part of deployment rather than block.xml I hope, so that blocks from different places not are going to kill each other.
What if I would like to mount a block in several places?.
No concept for this but I'm not sure wheter we will really need it.
I realized after I wrote the post that it probably don't make any sense for other people.
I have developed a way to use "polymorphic" sitemaps, that we make good use of in our webapps to reuse and extend common functionality. It doesn't require any extensions to Cocoon so I have forgoten to write about it. But it takes more than enough time to respond to my current RT, so I will not say anything more right now ;)
Part of the problem is that the sitemap is "non-declarative" in the sense that all matchers must be executed in order untill one matches before you know if a sitemap respond to a certain URL. While the BlockWiring mount is a little bit more declarative so that you can have a bidirectional mapping between the block protocol and "external" URLs. I think that it will confuse users to use both "declarative" and "procedural" mounts in the same application.
Personally I think that I prefer mounting both components and sitemaps from blocks in the application sitemaps that use them.
For me the strengh of the blocks concept is isolation. I deploy a block into my application and get a set of "services" that can be used:
I agree that the strengh is isolation. The reson for me to talk about locality is the case when you have a large webapp. The sub sitemaps can act as subapplications, and you might want to have them isolated from each other using different set of blocks. But I don't know if it is worthwhile.
- public components - pipelines - flowscripts (needs some more thinking how we define the interfaces but for me that's the even the most important service!)
I would assume that a (virtual) flowscript call should be very similar to a parametrized virtual pipeline (or maybe will they still be called resources?). The problem is the continuation handler. I would propose that the virtual flowscript definition must contain its continuation handler as well, otherwise the user of the flowscript must know block internal details about the continuation URL usage. Are there further problems?
<snip/>
/Daniel
