You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/10/12 15:29:17 UTC
Removed xdoc copying (Re: cvs commit: ...)
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
Re: SourceConf (Re: Removed xdoc copying)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Mon, Oct 13, 2003 at 11:07:27AM +0200, Nicola Ken Barozzi wrote:
...
>>The sourcemap is a descriptor for an inputmodule. This inputmodule gets
>>a "virtual" source location and resolves the real location.
>>
>>So from the sitemap, what it sees is just an inputmodule that gives it
>>the real source to use.
>
> So taking images as an example, which may be in
> src/documentation/resources/images or
> $FORREST/context/resources/images.
>
> What does the resources.xmap entry look like? It is currently:
>
> <map:match pattern="images/**.*">
> <map:read src="resources/images/{1}.{2}" mime-type="image/{2}" />
> </map:match>
>
> Perhaps:
>
> <map:match pattern="images/**.*">
> <map:read src="{images:{1}.{2}}" mime-type="image/{2}" />
> </map:match>
<map:match pattern="images/**.*">
<map:read src="{locationmap:content}" mime-type="image/{2}" />
</map:match>
"content" is a <matches> section for the content. I would add a "raw"
section and a "skin" section.
> which requires nesting variable resolution?
The resolved pattern is available as:
uri = ObjectModelHelper.getRequest(objectModel).getSitemapURI();
So in my locationmap I enter with the requested url and exit with the
source that has to be used for the URL. In this way I am able to cleanly
move all url resolving out of the sitemap.
What would be really nice is also a mimetype: inputmodule:
<map:match pattern="images/**.*">
<map:read src="{locationmap:content}" mime-type="{mimetype:}" />
</map:match>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
SourceConf (Re: Removed xdoc copying)
Posted by Jeff Turner <je...@apache.org>.
On Mon, Oct 13, 2003 at 11:07:27AM +0200, Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
>
> >On Sun, Oct 12, 2003 at 05:17:31PM +0200, Nicola Ken Barozzi wrote:
> ...
> >>In my sourcemap proposal, this is exactly what happens. The sourcemap
> >>tells me the real place of the file when I request a virtual place, by
> >>also using resource exists. I'll commit it as soon as it's finished
> >>(still working on the syntax as the current one still sucks).
> >
> >So how does it happen? ResourceExists actions, or ResourceExists input
> >modules?
>
> The sourcemap is a descriptor for an inputmodule. This inputmodule gets
> a "virtual" source location and resolves the real location.
>
> So from the sitemap, what it sees is just an inputmodule that gives it
> the real source to use.
So taking images as an example, which may be in
src/documentation/resources/images or
$FORREST/context/resources/images.
What does the resources.xmap entry look like? It is currently:
<map:match pattern="images/**.*">
<map:read src="resources/images/{1}.{2}" mime-type="image/{2}" />
</map:match>
Perhaps:
<map:match pattern="images/**.*">
<map:read src="{images:{1}.{2}}" mime-type="image/{2}" />
</map:match>
which requires nesting variable resolution?
--Jeff
...
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: Removed xdoc copying (Re: cvs commit: ...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Sun, Oct 12, 2003 at 05:17:31PM +0200, Nicola Ken Barozzi wrote:
...
>>In my sourcemap proposal, this is exactly what happens. The sourcemap
>>tells me the real place of the file when I request a virtual place, by
>>also using resource exists. I'll commit it as soon as it's finished
>>(still working on the syntax as the current one still sucks).
>
> So how does it happen? ResourceExists actions, or ResourceExists input
> modules?
The sourcemap is a descriptor for an inputmodule. This inputmodule gets
a "virtual" source location and resolves the real location.
So from the sitemap, what it sees is just an inputmodule that gives it
the real source to use.
Probably the proposed syntax is still too opaque, maybe this will be a
bit clearer. Note that the below snippet is exactly the same I already
sent to this list, just with a cleaner syntax.
<!-- the @default attribute says what default matcher is used to
mount, and the @base prefixes all sources.
Sources are resolves relative to the sourceconf location -->
<sourceconf xmlns:smap="http://apache.org/forrest/sourceconf/1.0"
default="wildcard"
base=".">
<!-- Asked for **.gif, return content/xdocs/{1}.gif -->
<mount pattern="**.gif">
<location src="content/xdocs/{1}.gif">
</mount>
<!-- Asked for **.xml, return the first location that exists -->
<mount pattern="**.xml">
<location src="content/xdocs/{1}.ihtml">
<location src="content/xdocs/{1}{2}.txt">
<location src="{default}">
</mount>
</sourceconf >
When I load this inputmodule I can specify a default sourceconf, so that
{default} can explicitly call the default version.
This had the benefit that users can add mount points easily.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Removed xdoc copying (Re: cvs commit: ...)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Oct 12, 2003 at 05:17:31PM +0200, Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
> >On Sun, Oct 12, 2003 at 12:51:32PM -0000, jefft@apache.org wrote:
> ...
> >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/
>
> Excellent! :-)
>
> ...
> >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.
>
> Welcome to sourcemaps :-P
>
> In my sourcemap proposal, this is exactly what happens. The sourcemap
> tells me the real place of the file when I request a virtual place, by
> also using resource exists. I'll commit it as soon as it's finished
> (still working on the syntax as the current one still sucks).
So how does it happen? ResourceExists actions, or ResourceExists input
modules?
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: Removed xdoc copying (Re: cvs commit: ...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Sun, Oct 12, 2003 at 12:51:32PM -0000, jefft@apache.org wrote:
...
> 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/
Excellent! :-)
...
> 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.
Welcome to sourcemaps :-P
In my sourcemap proposal, this is exactly what happens. The sourcemap
tells me the real place of the file when I request a virtual place, by
also using resource exists. I'll commit it as soon as it's finished
(still working on the syntax as the current one still sucks).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Removed xdoc copying
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Jeff Turner 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'.
...
> I am interested to see how this affects a site like Cocoon where
> its 'build docs' copies extra files into place before forrest starts,
> e.g. the jars.xml is prepared and copied to the build space.
>
> I started testing with their 'build docs' but got this break.
> Is it related?
I don't know if it's related, but it should not if things are done
correctly. The files should be copied in place *before* starting
Forrest, and Forrest should be pointed to that place for looking for
source files.
In any case, I'll be moving this system to use the locationmap instead
shortly, so we'll have to do a check after that.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Removed xdoc copying
Posted by David Crossley <cr...@indexgeo.com.au>.
Jeff Turner 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}'.
I am interested to see how this affects a site like Cocoon where
its 'build docs' copies extra files into place before forrest starts,
e.g. the jars.xml is prepared and copied to the build space.
I started testing with their 'build docs' but got this break.
Is it related?
--------
X [0] index.html BROKEN:
/usr/local/cvs/cocoon-2.1/build/cocoon-2.1.3-dev/tmp/context/content/xdocs/tabs.xml (No such file or directory)
* [0/0] 0.309s 766b favicon.ico
Total time: 0 minutes 16 seconds
BUILD FAILED
/usr/local/cvs/xml-forrest/build/dist/shbat/forrest.build.xml:642: Java
returned: 1
Total time: 57 seconds
BUILD FAILED
file:/usr/local/cvs/xml-forrest/build/dist/shbat/forrest.antproxy.xml:45: Java returned: 1
--------
Re: Removed xdoc copying (Re: cvs commit: ...)
Posted by Eric BURGHARD <eb...@free.fr>.
Le Dimanche 12 Octobre 2003 15:29, Jeff Turner a écrit :
> 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'.
Smart solution
Great ! because between forrest webapp, forrest backcopy, and cvs commit (for
my site reposirory) i was lost sometimes.