forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Leather and global variables
Date Tue, 15 Mar 2005 22:42:40 GMT
On Tue, 2005-03-15 at 10:08 +0000, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Mon, 2005-03-14 at 12:12 +0000, wrote:
> > 
> > I need some input on the following:
> > 
> > 
> >>+<!--This should be match to the conf dir but I do not know ┬┐how?
> >>+          {project:conf-dir} does not work -> ask on ml!
> >>+          For now that matches the default.fv in the xdocs dir.
> >>+          The problem with this solution is that the a default.xml will be always
render with the default view.
> >>+          Not too bad of a problem after all ;-)-->
> > 
> > 
> > Where do we define this global variables? 
> Do you mean where do we define *new* global variables that can be set in 
> If so the answer is cocoon.xconf.

hmm, ok, I tried:
Index: main/webapp/WEB-INF/xconf/forrest-core.xconf
--- main/webapp/WEB-INF/xconf/forrest-core.xconf        (revision
+++ main/webapp/WEB-INF/xconf/forrest-core.xconf        (working copy)
@@ -139,6 +139,7 @@

+        <conf-dir>@project.conf-dir@</conf-dir>



...but I could not find any target that would do e.g.

Can you please give me another hint how to use {project:conf-dir} within
my output.xmap

> > Now to the changes of the fbits-plugin in regards to leather.
> I'll have a look at that as soon as I can, should be in a day or two.
> > 
> > The missing steps are just a matter of implementing (change the default
> > "skinit" pipe and capsuled all code of the site2xhtml.xsl). I am working
> > on that (including document2xhtml and css) right now but I am "scared"
> > to commit it (because I do not have the time to test it appropriately
> > and it will alter the default behavior of forrest), so I will prepare a
> > patch or open a new branch (what do you prefer?) for the upcoming
> > changes.
> We definitely *don't* want to go messing with core before the 0.7 release.

That is why I said if I will touch the core I will prepare a patch or
will create a new branch. ;-)

> Have you considered using an internal plugin? You can (theoretically) 
> override anything in the core sitemaps using an internal plugin. This 
> sounds like a brilliant use case for complete testing of internal 
> plugins (only the IMSManifest plugin exists so far).

Yeah, I will try that.

> Working with it as an Internal plugin will prevent any branch merge 
> conflicts at a later date. Of course we will still be able to move it 
> into core if and when necessary.

ok, I will try the internal plugin ASAP.


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message