cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Cleanup forms/samples/resources
Date Wed, 01 Dec 2004 22:41:57 GMT
Reinhard Poetz wrote:

> Sylvain Wallez wrote:
>> Reinhard Poetz wrote:
>>> After working a lot with cForms the last week I was fed up by 
>>> looking at the resources directory and always having a sense of 
>>> staring at a big mess. I moved all images, css and js into their own 
>>> directories. Unfortunatly this broke templates that reference images 
>>> directly. As cForms are not stable I wouldn't care about this (it 
>>> won't be the last thing that changes until we mark cForms as stable) 
>>> and simply add a release note but if others think different, I could 
>>> add an additional pipeline for gifs.
>> As the number of resources is growing, it is good to organize them 
>> and creating subdirectories is ok. However, we must keep them under a 
>> single root resource dir to allow a simple <map:read> to serve any of 
>> these resources.
> I agree
>> Too often I see sitemaps having a myriad of simple match/read for 
>> *.gif, *.jpeg, *.js, *.css, etc when a simple <match 
>> pattern="resources/**"> would do the job.
>> Also, now that these resources have stabilized, we may move them into 
>> the cform's jar, in order to avoid copy/pasting them in every 
>> project. The resources pipeline would then become:
>> <map:match pattern="form-rsrc/**">
>>  <map:read src="resource://org/apache/cocoon/forms/resources/{1}"/>
>> </map:match>
>> WDYT?
> This is good for our users who don't have to copy around things and 
> upgrading between Cocoon releases should become easier for them.
> For developers working on e.g. the stylesheets this only requires one 
> change so that map:read points directly to their SVN source tree.

Yes. Or you can also, as I sometimes to, use the ParanoidCocoonServlet 
with a classpath set to Eclipse's build directory 
(build/eclipse/classes) where resources are automatically copied.

That avoids modifying the the sitemap to read in the source tree, which 
will also avoid use to inadvertently commit it :-)

> Another question: currently all XSLTs are in the base directory of 
> resources. As we only support HTML at the moment, this is not a 
> problem.  But where do we put e.g. a XUL stylesheet so that we don't 
> end up in a big mess?
> I propose
> /resources
> /resources/stylesheets
> /resources/stylesheets/html
> /resources/stylesheets/xul
> /resources/stylesheets/lazlo
> /resources/img
> /resources/js
> ...

Sounds good.

For the record, I initially added stylesheets in the resources dir along 
with client-side files in order to allow the XSLs to be transmitted to 
XSL-aware browsers. Now I never actually tested that browsers could 
effectively run these stylesheets...


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message