Daniel Fagerstrom wrote:
Looks good!
I will restructure the cocoon-blocks-fw projects so that it contains sub
projects, then we can move the Schema files and configuration model
beans, so that we share a common implementation.
yes, good idea.
I will also synchronize the schema files as I changed them a bit compared to the
files in /trunk/src
With configuration model beans you mean the classes generated by Castor, don't
you?
Do you have the intention to use the Castor classes in core? I'm not really
convinced we should do this as Castor comes with some dependencies and as core
mostly (only?) needs reading access to the configuration files, I think we
should use something that doesn't introduce so many (or any) dependencies.
I will also create a block based sample webapp, so that it is easier to
see how the blocks framework is used.
yes, samples are good :-)
I think the details about configurations and directory structure is
better to start to discuss when we start to integrate our work. It is
worth mentioning though that the sitemap element of the block
configuration will be replaced with a servlet element or maybe even a
servlets element:
<servlet class="org.apache.cocoon.sitemap.SitemapServlet">
// SitemapServlet specific configuration
<sitemap>
// ...
</sitemap>
</servlet>
As we, (as discussed in the NG threads) want to be able to use other
controllers than the sitemap as top level controller in Cocoon it would
IMO be a bad idea to hardwire the blocks framework to the concept of
sitemaps.
ok, will adapt the schema file then.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
