Leszek Gawron wrote:
other example that I posted some time ago: if every cocoon uses
error2html.xsl by default (along with some other default resources)
they should be also packed into jars.
Aha! This is something I wanted to talk about when working on Cocoon
stacktraces: standardizing the fact that some blocks provide resources
and include them in jars.
The first block to do this is CForms, which provides a lot of runtime
resources in org/apache/cocoon/forms/resources: XSLs, js, css, etc. We
also have a few items for the core block in webapp/stylesheets/system
and webapp/resources (js and css). What we see here is that these are
runtime resources targeted both at the server side (XSLs) and the client
side (js, css and also XSLs for xsl-aware browsers).
What I propose is that we define a standard layout for resources
provided by blocks: they should be stored in
resource://org/apache/cocoon/{block-name}/resources/
Additionally, we should have a system-defined URI which allows clients
to fetch these resources, implemented in the root sitemap:
<map:match pattern="_cocoon_/*/**">
<map:read src="resource://org/apache/cocoon/{1}/resources/{2}"/>
</map:match>
By standardizing this URI pattern, we can easily solve cross-referencing
problems among resources, e.g. CForms XSLs having to produce <script
src="..."/> to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
