forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: In-place editing (Re: [RT] Forrest source directory layout and resolving)
Date Sun, 05 Oct 2003 07:59:23 GMT
Jeff Turner wrote:

> On Sat, Oct 04, 2003 at 11:54:24PM +0200, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote:
>>>On Wed, Sep 24, 2003 at 11:30:10AM +0200, Nicola Ken Barozzi wrote:
>>>>We need to tackle the Forrest source directory layout and how to resolve 
>>>>additional source dirs.
>>>>2 no more source copying
>>>This is the one I'm personally interested in tackling right now.
>>>Actually I've prototyped much of this locally.  It works (XML can be
>>>edited in-place) but isn't complete yet.  I've placed my experiments
>>>online at:
>>Since I really want to get this thing done, I have looked at the above 
>>mentioned files, and I've seen that there is still a mixture of two 
>>places where the sources are defined:
>> 1 - an xml config file
> Which XML config file?

In cocoon.xconf, but in the future it could be in an external descriptor 

I would like to remove all of the definitions in cocoon.xconf, as it 
prohibits us to use a single Cocoon for multiple forrest websites.

>> 2 - the sources xmap
>>>From our last discussion we had seen that using a sources xmap could be 
>>the best course of action, as it gives the greatest flexibility and 
>>makes it possible for users to start understanding Cocoon.
>>But it also exposes us to possible problems in the future when we would 
>>want to change the sitemaps. In fact I have the feeling that part of the 
>>blame of our slow speed is due to splitted sitemaps and continuous 
>>calling of cocoon://, although I haven't yet tested it.
> Probably.  Using cocoon: URLs to look up skin resources (XSLTs, images,
> css etc) won't help matters.
>>Hence, probably a definition of dirs and additional sources could also 
>>be done in the config file...
> I don't understand how sources can be defined in a config file external
> to the sitemap..

By using an input module that resolves sources from an xml definition 
file, or by using a special protocol (ie forrest://).

A quite simple solution would be to put the loading of the file in the 
declaration of this input module, but again this would force us to keep 
multiple Forrest webapps in the same webapp container.

So it seems that the loading of this file would have to be done per 
invocation, with caching, but I'm still thinking about how to get it 

>>><map:mount uri-prefix="" src="cocoon://forrest.xmap" check-reload="yes" />
>>Hmmm... does it work? I thought mounts were done at startup. In any case 
>>the idea is very nice.
> Doesn't work unfortunately:
> java.lang.NullPointerException
>         at org.apache.cocoon.environment.AbstractEnvironment.release(
>         at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(
>         at org.apache.cocoon.generation.FileGenerator.recycle(
> Although I don't see why it shouldn't work.  Looks like a bug.

Semantically you are correct, but from an implementation POV I can 
understand why it is made this way (similarly to xinclude).

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message