Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <426B79AB.1000206@nada.kth.se>
Date: Sun, 24 Apr 2005 12:49:15 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: block.xml and the blocks sitemap
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The block descriptor file contains a reference to the root sitemap of 
the block. In Cocoon the main configuration (cocoon.xconf) is the 
starting point instead. In the http environment the configuration file 
can be defined in web.xml or is taken from its default position. Then 
the root processor is configured with e.g.:

   <sitemap file="context://sitemap.xmap"/>

Starting from the sitemap instead of from the configuration could 
simplify things for the blocks authors as they don't need to write a 
configuration file for a simple block and can define the compnents in 
the sitemap instead.

But there is still the question how the block sitemap should be 
configured, should it get the reload parameter from the Cocoon root 
sitemap, and what about the config attribute? Also there is the question 
if there should be a "block.xconf" and how it should be related to the 
sitemap.

IMO we should have the same behaviour in blocks as in the "main Cocoon". 
So if we have the sitemap as "main configuration" in blocks we should 
allow the same in the "main Cocoon".

To simplify prototyping of the block manager I let block.xml point at 
the block configuration file instead as a temporary solution.

                       --- o0o ---

So, what is your opinions about this, has it been discussed before?

/Daniel