Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Date: Sun, 12 Oct 2003 23:29:17 +1000
From: Jeff Turner <jefft@apache.org>
To: forrest-dev@xml.apache.org
Cc: Andreas Hartmann <andreas@apache.org>
Subject: Removed xdoc copying (Re: cvs commit: ...)
Message-ID: <20031012132917.GA9715@expresso.localdomain>
Mail-Followup-To: forrest-dev@xml.apache.org,
	Andreas Hartmann <andreas@apache.org>
References: <20031012125132.93799.qmail@minotaur.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031012125132.93799.qmail@minotaur.apache.org>
User-Agent: Mutt/1.5.4i

On Sun, Oct 12, 2003 at 12:51:32PM -0000, jefft@apache.org wrote:
> jefft       2003/10/12 05:51:32
> 
>   Modified:    src/resources/conf cocoon.xconf faq.xmap forrest.xmap
>                         linkmap.xmap menu.xmap resources.xmap
>                         revisions.xmap sitemap.xmap
>                src/resources/forrest-shbat forrest.build.xml
>   Log:
>   Remove the need to copy xdocs to a temporary webapp. xdocs can now be edited in
>   their original directory and updates seen live, eg. when using 'forrest run'.

As you can see, I've made a start on in-place editing of content.  After
typing 'forrest run', XML can be edited in
src/documentation/content/xdocs/ and changes will appear on
http://localhost:8888/

This is done very simply with a 'project' DefaultsMetaModule, and every
occurrence of 'content/xdocs/' replaced with '{project:content.xdocs}'.

   
                              --oOo--


Lurking on lenya-dev, I saw a neat solution for how we can handle static
things like stylesheets, which exist in
$FORREST_HOME/resources/stylesheets, but may be overridden by the user in
src/documentation/resources/stylesheets/.  Namely, in the sitemap we use
(for example) '{stylesheet:changes2document.xsl}', and let an inputmodule
decide which path to use - either the overridden file, or the default.

To make this work, I wrote a ResourceExistsModule which interprets its
input as a path, and returns null if that path doesn't exist.  By putting
two of these in a ChainMetaModule, we achieve 'fallback' behaviour.  Here
is how the 'stylesheets' module is defined:

  <!-- Declare our components -->
  <component-instance
    class="org.apache.cocoon.components.modules.input.ResourceExistsModule"
    logger="core.modules.mapper" name="exists"/>
  <component-instance
    class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
    logger="core.modules.mapper" name="mapper"/>
  
  <component-instance logger="core.modules.input" name="stylesheets"    class="org.apache.cocoon.components.modules.input.ChainMetaModule">
  
     <!-- Overridden stylesheet, if any -->
     <input-module name="mapper">       <!-- Add a prefix (the path) to the key (eg 'changes2document.xsl') -->
      <input-module name="exists"/>     <!-- If the full path exists, return it, otherwise return null -->
      <prefix>/home/jeff/apache/xml/xml-forrest/src/documentation/resources/stylesheets/</prefix>
    </input-module>
  
     <!-- Default stylesheet.  Only used if overridden stylesheet doesn't exist -->
     <input-module name="mapper">
      <input-module name="exists"/>
      <prefix>/home/jeff/apache/xml/xml-forrest/build/dist/shbat/context/resources/stylesheets/</prefix>
    </input-module>
  
  </component-instance>


The Lenya equivalent is a FallbackModule which hardcodes the paths - this
is just a generic equivalent.  I'll see about adding this
ResourceExistsModule to Cocoon CVS, so we can potentially use the same
thing.

Unfortunately this solution doesn't generalize to other possibly
overridden files like images, because we don't know the image name
beforehand, and we can't have {images:{1}} because the sitemap doesn't
allow nested variable interpolation.  Need to ping cocoon-dev and find
out if nested variables can be supported..

Hope everyone had a similarly fun weekend. ;P


--Jeff