You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/10/04 23:54:24 UTC
Re: In-place editing (Re: [RT] Forrest source directory layout and
resolving)
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:
>
> http://www.apache.org/~jefft/forrest/samples/xml-forrest-vfs.tgz
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
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.
Hence, probably a definition of dirs and additional sources could also
be done in the config file...
>>Why do we have to copy the sources?
>
> Because:
>
> 1) We let users define their site structure however they want, yet our
> sitemap expects a certain format.
...
> 2) We allow projects to override Forrest files:
>
> 2.1) If I have src/documentation/skins/forrest-site/css/page.css, it
> overrides that from the Forrest skin. This applies to *any* skin file.
Till no wit's easy...
...
> 2.2) Sitemaps can be overridden. If my project has a
> src/documentation/conf/sitemap.xmap, I want it to be used instead of the
> default.
>
> Two options for solving this:
>
> 1) We keep the existing solution of physically copying and overwriting
> xmap files.
>
> 2) We apply the 'virtual filesystem' pattern, and mount dynamically
> chosen sitemaps:
>
> <map:mount uri-prefix="" src="cocoon://forrest.xmap" check-reload="yes" />
Cool!
Hmmm... does it work? I thought mounts were done at startup. In any case
the idea is very nice.
This makes me think even more that we need to have at least some config
info in an external file, so that normal uses would have to go without
touching the sitemaps.
> We have a bootstrap problem with sitemap.xmap itself, although looking in
> cocoon.xconf, I see it is located with 'context://sitemap.xmap', so
> perhaps there's room for abstracting the location.
As long as we keep sitemap.xmap containing only mounts, it should not be
necessary to extend it... hmmm...
...
> 3) We rely on @tokens@ in breadcrumbs.js
This can be fixed as you say with a text generator and a
search-and-replace on it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: In-place editing (Re: [RT] Forrest source directory layout and
resolving)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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:
>>>
>>>http://www.apache.org/~jefft/forrest/samples/xml-forrest-vfs.tgz
>>
>>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
file.
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
resolved.
>>><map:mount uri-prefix="" src="cocoon://forrest.xmap" check-reload="yes" />
>>
>>Cool!
>>
>>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(AbstractEnvironment.java:521)
> at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:332)
> at org.apache.cocoon.generation.FileGenerator.recycle(FileGenerator.java:89)
>
> 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: In-place editing (Re: [RT] Forrest source directory layout and resolving)
Posted by Jeff Turner <je...@apache.org>.
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:
> >
> >http://www.apache.org/~jefft/forrest/samples/xml-forrest-vfs.tgz
>
> 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?
> 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..
> >
> ><map:mount uri-prefix="" src="cocoon://forrest.xmap" check-reload="yes" />
>
> Cool!
>
> 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(AbstractEnvironment.java:521)
at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:332)
at org.apache.cocoon.generation.FileGenerator.recycle(FileGenerator.java:89)
Although I don't see why it shouldn't work. Looks like a bug.
--Jeff
...
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>