Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
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/
The nice thing with this propsal is that it is back compatible and
follow current (emerging) conventions. OTH with the blocks
architecture, using the resource protocol is not such a good idea. In
OSGi resources have URLs like bundle://3/org.apache.cocoon.foo e.g.
where "3" is the number of the bundle and is deployment order
dependent and is therefore not usable in sitemaps. In OSGi one
typically puts the resources at the top level of the jar or in
directories at top level. There is normally not that much reason for
puting resources in the Java package structure, as the bundle poften
is an apropriate level of granularity anyway.
Hmm... as I understand it, the bundle: protocol is similar to what is
returned by ClassLoader.getResource(), and is abstracted by the
resource: protocol implementation (it can actually be a jar: or a file:
or something else that we never see).
And BTW, unless I missed something I haven't seen an explicit reference
to the "bundle:" protocol in the OSGi specs, at least in R3.
We also have the block protocol that allows you to define what block
the resource is taken from: block:foo:/bar.xsl. Now the block protocol
assumes that everything is exported through the sitemap wich might be
appropriate (but maybe inconvenient) for the use cases you have in
mind. Maybe we could have an own bundle protocol (through the source
mechanism), that works like the OSGi bundle protocol but have symbolic
block names instead of bundle numbers.
Something like "block-resource://org.apache.cocoon.forms/..." ?
This can be implemented today in 2.1.x by having this protocol
delegating to "resource:"
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}.
All this is allready solved within the (sitemap) block architecture
and there is an implementation of it in trunk. block URIs are used for
accessing things and a special URL rewriting transformer absolutizes
the block URLs.
I'm proposing here a public URL pattern that can be accessed by
browsers. Block URIs are an internal thing and this pattern must be
implemented somewhere, no?
WDYT?
Your proposal makes sense and we should make something about the
issues you describe. What you describe will not be particulary future
proof though.
So how do we make it future proof yet possible in 2.1.x? Can we have a
single naming scheme (with a new protocol) implemented differently or
pointing to different locations (the 'resources' dir can be located at
the top-level of a bundle)?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
