You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/03/22 09:17:19 UTC
[C2]: Understanding mount
Hi,
I am currently playing a little bit with mounting subsitemaps.
After a while I got it working now, but I am still wondering
what the exact purpose of the attributes uri-prefix and src is.
I used the following mount-example from the sitemap draft:
<map:match pattern="dist/*">
<map:mount uri-prefix="dist/" src="dist/{1}"/>
</map:match>
This generates the following source:
return sitemapManager.invoke (environment,
substitute(listOfLists, "dist/"),
substitute(listOfLists, "dist/{1}"), true);
The third argument ("substitute(listOfLists, "dist/{1}")") is the
source argument for the sitemap handler to load the new sitemap.
So if I try to load the resource "dist/hello" the sitemap
"dist/hello/sitemap.xmap" is tried to loaded. When I try to load
"dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
to loaded. And so on.
So I assume from this, that the "src" attribute indicates the location of the subsitemap.
This would lead to:
<map:match pattern="dist/*">
<map:mount uri-prefix="dist/" src="dist/subsitemap.xmap"/>
</map:match>
The "uri-prefix" seems to be the part which has to be removed from the uri,
this means sending the request "dist/welcome" will remove "dist/" from the
uri and only "welcome" is passed to the subsitemap.
So I could use
<map:match pattern="hallo">
<map:generate src="test.xml"/>
<map:serialize type="xml"/>
</map:match>
in the "dist/subsitemap.xmap" to match the request.
This example above works fine. Am I using the attributes correcly?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Understanding mount (Testing root level mount points)
Posted by Carsten Ziegeler <cz...@sundn.de>.
I just updated the sitemap documentation a little bit (renamed Choosers and Filters)
and added the "raw" mails.
Next week I have more time to clean up the documentation further.
Carsten
> Giacomo Pati wrote:
>
> Carsten Ziegeler wrote:
> >
> > > Santiago Gala wrote
> > >
> > > I have not commit rights, but I would post this mail as is in the
> > > documents, linked from the sitemap documentation.
> > >
> > > It opens a new world of possibilities for cocoon I had never thought
> of,
> > > like virtual hosting, separate mounting of webapps, ...
> > >
> > > <snip>
> >
> > Yes, I agree. As soon as I have time I will update the docs with this
> stuff,
> > including the email and Giacomos explanations.
>
> +1000
>
> Thanks
>
> Giacomo
>
> >
> > Just give me a little bit time...
> >
> > Carsten
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Understanding mount (Testing root level mount points)
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
>
> > Santiago Gala wrote
> >
> > I have not commit rights, but I would post this mail as is in the
> > documents, linked from the sitemap documentation.
> >
> > It opens a new world of possibilities for cocoon I had never thought of,
> > like virtual hosting, separate mounting of webapps, ...
> >
> > <snip>
>
> Yes, I agree. As soon as I have time I will update the docs with this stuff,
> including the email and Giacomos explanations.
+1000
Thanks
Giacomo
>
> Just give me a little bit time...
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Understanding mount (Testing root level mount points)
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Santiago Gala wrote
>
> I have not commit rights, but I would post this mail as is in the
> documents, linked from the sitemap documentation.
>
> It opens a new world of possibilities for cocoon I had never thought of,
> like virtual hosting, separate mounting of webapps, ...
>
> <snip>
Yes, I agree. As soon as I have time I will update the docs with this stuff,
including the email and Giacomos explanations.
Just give me a little bit time...
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount (Testing root level mount points)
Posted by Santiago Gala <sg...@hisitech.com>.
I have not commit rights, but I would post this mail as is in the
documents, linked from the sitemap documentation.
It opens a new world of possibilities for cocoon I had never thought of,
like virtual hosting, separate mounting of webapps, ...
Giacomo Pati wrote:
> Colin Britton wrote:
>
>>>> Can a map:mount be inside a map:select like this...
>>>
>> <snip/>
>>
>>> From the sitemap.xsl logicsheet there is no limitation on where a
>>> map:mount should be and thus are free to place it where you want.
>>
>> <snip/>
>>
>>> Well, haven't thought about replacing the root URI with different
>>> sitemaps but I'd like you to test it and report your experience on this
>>> list :)
>>
>> So here goes. The aim of my tests was to see how the sitemap mount function
>> could be used to simplfy the creation and management of cocoon2 based sites
>> and applications. We have a good size server (quad processor PIII server
>> with plenty of ram and HD) and wish to deploy multiple clents work and
>> multiple applications on the same box. Now we could (and will) setup
>> multiple http servers and therefore multiple servlet environments and
>> multiple Cocoon applications. But this creates a lot of admin and multiple
>> versions of items and all the heartache that comes with it.
>>
>> I wanted to see if we could solve the following problems within the cocoon
>> environment.
>>
>> 1) Simplify site construction
>> 2) Reduce risk of "bad' sitemap entries killing whole site
>> 3) Ease deployment of pre-built applications
>> 4) Keep sitemap files an understandable and manageable size
>>
>> The short answer is that the sitemap and in particular the mount function
>> does a good job of meeting my goals.
>
>
> What we allways thought of it should be but never were able to test it
> so far :)
>
>
>> My test was such.
>>
>> I build a main sitemap, for C2 to load This sitemap is the minimum it needs.
>> A matcher and a selector. These two components allow me to select and direct
>> to mount two other site maps.
>>
>> These sub-sitemaps load the componants they need (which includes generators
>> and transformers etc...) and have the map elements for that
>> site/application.
>
>
> Take into account that sitemap components (generators, transformers,
> etc.) in a sitemap are accessible by a sub-sitemap by their names. This
> is due to the fact that each sitemap has its own SitemapComponentManager
> and they are arranged in the same hierarchical structure as the sitemaps
> are and thus knows which are their parent SitemapComponentManager and
> can ask it for a SitemapComponent it doesn't know about.
>
>
>> The benefit is that each sitemap is completely independant of each other and
>> any error in that sitemap does not kill any other sitemap. This seems to
>> work pretty well. I ran this up and deliberatly broke a sitemap and the
>> other one still ran.
>
>
> But usually you use the same SitemapComponents over and over again in
> your sub-sitemaps. And because you have a contract between the parent
> and sub sitemaps (the uri-prefix) you can deliver common
> SitemapComponents from the parent sitemap to your sub-sitemaps as well.
>
> Also note that if you break a sitemap all its sub-sitemaps are broken as
> well (because of the hierarchical arragement).
>
>
>> The benefit is I can build a seperate app or site on another machine, test
>> it offline and deploy it on the main server with minimal risk and
>> distruption. A huge win.
>
>
> This is why sub sitemaps were introduced: scalability.
>
> SIDENOTE: This is why there is an EntityResolver argument in the
> signature of the SitemapModelComponent interface. When a subsitemap is
> mounted the sitemap engine reports the uri-prefix and the context (src)
> to the calling Environment (changeContext method) so that
> SitemapComponent (i.e. URIMatcher) requesting a URI don't see the prefix
> and if for example a generator needs to resolve an src resource the
> EntityResolver (implemented by the calling Environment) is responsible
> to resolve that to the changed context the subsitep is in.
>
>
>> Here is my main sitemap. You will notice that I am using a selector that
>> matches on host name of the request, but any matcher or selector would work
>> at this point. I am mounting both sub-sitemaps at the root level.
>>
>> <?xml version="1.0"?>
>> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
>> <!-- =========================== Components
>> ================================ -->
>> <map:components>
>> <map:matchers default="wildcard">
>> <map:matcher name="wildcard"
>> factory="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
>> </map:matchers>
>>
>> <map:selectors default="host">
>> <map:selector name="host"
>> factory="org.apache.cocoon.selection.HostSelectorFactory">
>> <host name="fee" value=www.foo.com/>
>> </map:selector>
>> </map:selectors>
>>
>> </map:components>
>> <!-- =========================== Pipelines
>> ================================= -->
>> <map:pipelines>
>> <map:pipeline>
>>
>> <map:select type="host">
>> <map:when test="fee">
>> <map:mount uri-prefix="" src="fee.xmap"/>
>> </map:when>
>> <map:otherwise>
>> <map:mount uri-prefix="" src="foo.xmap"/>
>> </map:otherwise>
>> </map:select>
>>
>> </map:pipeline>
>> </map:pipelines>
>> </map:sitemap>
>> <!-- end of file -->
>
>
> This is cool. Mounting different sitemaps on to the root URI :)
>
>
>> So this is a cool way to build out a cocoon2 app/site.
>>
>> Comments and ideas....
>
>
> Thanks for your investigations.
>
> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount (Testing root level mount points)
Posted by Giacomo Pati <gi...@apache.org>.
Colin Britton wrote:
>
> > > Can a map:mount be inside a map:select like this...
> <snip/>
> > From the sitemap.xsl logicsheet there is no limitation on where a
> > map:mount should be and thus are free to place it where you want.
> <snip/>
> > Well, haven't thought about replacing the root URI with different
> > sitemaps but I'd like you to test it and report your experience on this
> > list :)
>
> So here goes. The aim of my tests was to see how the sitemap mount function
> could be used to simplfy the creation and management of cocoon2 based sites
> and applications. We have a good size server (quad processor PIII server
> with plenty of ram and HD) and wish to deploy multiple clents work and
> multiple applications on the same box. Now we could (and will) setup
> multiple http servers and therefore multiple servlet environments and
> multiple Cocoon applications. But this creates a lot of admin and multiple
> versions of items and all the heartache that comes with it.
>
> I wanted to see if we could solve the following problems within the cocoon
> environment.
>
> 1) Simplify site construction
> 2) Reduce risk of "bad' sitemap entries killing whole site
> 3) Ease deployment of pre-built applications
> 4) Keep sitemap files an understandable and manageable size
>
> The short answer is that the sitemap and in particular the mount function
> does a good job of meeting my goals.
What we allways thought of it should be but never were able to test it
so far :)
> My test was such.
>
> I build a main sitemap, for C2 to load This sitemap is the minimum it needs.
> A matcher and a selector. These two components allow me to select and direct
> to mount two other site maps.
>
> These sub-sitemaps load the componants they need (which includes generators
> and transformers etc...) and have the map elements for that
> site/application.
Take into account that sitemap components (generators, transformers,
etc.) in a sitemap are accessible by a sub-sitemap by their names. This
is due to the fact that each sitemap has its own SitemapComponentManager
and they are arranged in the same hierarchical structure as the sitemaps
are and thus knows which are their parent SitemapComponentManager and
can ask it for a SitemapComponent it doesn't know about.
> The benefit is that each sitemap is completely independant of each other and
> any error in that sitemap does not kill any other sitemap. This seems to
> work pretty well. I ran this up and deliberatly broke a sitemap and the
> other one still ran.
But usually you use the same SitemapComponents over and over again in
your sub-sitemaps. And because you have a contract between the parent
and sub sitemaps (the uri-prefix) you can deliver common
SitemapComponents from the parent sitemap to your sub-sitemaps as well.
Also note that if you break a sitemap all its sub-sitemaps are broken as
well (because of the hierarchical arragement).
> The benefit is I can build a seperate app or site on another machine, test
> it offline and deploy it on the main server with minimal risk and
> distruption. A huge win.
This is why sub sitemaps were introduced: scalability.
SIDENOTE: This is why there is an EntityResolver argument in the
signature of the SitemapModelComponent interface. When a subsitemap is
mounted the sitemap engine reports the uri-prefix and the context (src)
to the calling Environment (changeContext method) so that
SitemapComponent (i.e. URIMatcher) requesting a URI don't see the prefix
and if for example a generator needs to resolve an src resource the
EntityResolver (implemented by the calling Environment) is responsible
to resolve that to the changed context the subsitep is in.
> Here is my main sitemap. You will notice that I am using a selector that
> matches on host name of the request, but any matcher or selector would work
> at this point. I am mounting both sub-sitemaps at the root level.
>
> <?xml version="1.0"?>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <!-- =========================== Components
> ================================ -->
> <map:components>
> <map:matchers default="wildcard">
> <map:matcher name="wildcard"
> factory="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
> </map:matchers>
>
> <map:selectors default="host">
> <map:selector name="host"
> factory="org.apache.cocoon.selection.HostSelectorFactory">
> <host name="fee" value=www.foo.com/>
> </map:selector>
> </map:selectors>
>
> </map:components>
> <!-- =========================== Pipelines
> ================================= -->
> <map:pipelines>
> <map:pipeline>
>
> <map:select type="host">
> <map:when test="fee">
> <map:mount uri-prefix="" src="fee.xmap"/>
> </map:when>
> <map:otherwise>
> <map:mount uri-prefix="" src="foo.xmap"/>
> </map:otherwise>
> </map:select>
>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
> <!-- end of file -->
This is cool. Mounting different sitemaps on to the root URI :)
> So this is a cool way to build out a cocoon2 app/site.
>
> Comments and ideas....
Thanks for your investigations.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount (Testing root level mount points)
Posted by Colin Britton <cb...@centervilletech.com>.
> > Can a map:mount be inside a map:select like this...
<snip/>
> From the sitemap.xsl logicsheet there is no limitation on where a
> map:mount should be and thus are free to place it where you want.
<snip/>
> Well, haven't thought about replacing the root URI with different
> sitemaps but I'd like you to test it and report your experience on this
> list :)
So here goes. The aim of my tests was to see how the sitemap mount function
could be used to simplfy the creation and management of cocoon2 based sites
and applications. We have a good size server (quad processor PIII server
with plenty of ram and HD) and wish to deploy multiple clents work and
multiple applications on the same box. Now we could (and will) setup
multiple http servers and therefore multiple servlet environments and
multiple Cocoon applications. But this creates a lot of admin and multiple
versions of items and all the heartache that comes with it.
I wanted to see if we could solve the following problems within the cocoon
environment.
1) Simplify site construction
2) Reduce risk of "bad' sitemap entries killing whole site
3) Ease deployment of pre-built applications
4) Keep sitemap files an understandable and manageable size
The short answer is that the sitemap and in particular the mount function
does a good job of meeting my goals.
My test was such.
I build a main sitemap, for C2 to load This sitemap is the minimum it needs.
A matcher and a selector. These two components allow me to select and direct
to mount two other site maps.
These sub-sitemaps load the componants they need (which includes generators
and transformers etc...) and have the map elements for that
site/application.
The benefit is that each sitemap is completely independant of each other and
any error in that sitemap does not kill any other sitemap. This seems to
work pretty well. I ran this up and deliberatly broke a sitemap and the
other one still ran.
The benefit is I can build a seperate app or site on another machine, test
it offline and deploy it on the main server with minimal risk and
distruption. A huge win.
Here is my main sitemap. You will notice that I am using a selector that
matches on host name of the request, but any matcher or selector would work
at this point. I am mounting both sub-sitemaps at the root level.
<?xml version="1.0"?>
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<!-- =========================== Components
================================ -->
<map:components>
<map:matchers default="wildcard">
<map:matcher name="wildcard"
factory="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
</map:matchers>
<map:selectors default="host">
<map:selector name="host"
factory="org.apache.cocoon.selection.HostSelectorFactory">
<host name="fee" value=www.foo.com/>
</map:selector>
</map:selectors>
</map:components>
<!-- =========================== Pipelines
================================= -->
<map:pipelines>
<map:pipeline>
<map:select type="host">
<map:when test="fee">
<map:mount uri-prefix="" src="fee.xmap"/>
</map:when>
<map:otherwise>
<map:mount uri-prefix="" src="foo.xmap"/>
</map:otherwise>
</map:select>
</map:pipeline>
</map:pipelines>
</map:sitemap>
<!-- end of file -->
So this is a cool way to build out a cocoon2 app/site.
Comments and ideas....
rgds
CB
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount
Posted by Giacomo Pati <gi...@apache.org>.
Colin Britton wrote:
>
> Can a map:mount be inside a map:select like this...
>From the sitemap.xsl logicsheet there is no limitation on where a
map:mount should be and thus are free to place it where you want.
> We have written a
> selector that matches on the host header so we can serve multiple
> domains/servers on the same cocoon instance and were just starting to look
> at sitemap structure for this.
>
> <map:match pattern="/">
> <map:select type="host">
> <map:when test="foo.com">
> <map:mount uri-prefix="/" src="foo_sitemap.xmap"/>
> </map:when>
> <map:otherwise>
> <map:mount uri-prefix="/" src="fee_sitemap.xmap"/>
> </map:otherwise>
> </map:select>
> </map:match>
Well, haven't thought about replacing the root URI with different
sitemaps but I'd like you to test it and report your experience on this
list :)
> do you want me to post the selector?
Sure, why not? Send it as zip to me (and please put some javadocs into
it to document the functionality and usage of your selector)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount
Posted by Colin Britton <cb...@centervilletech.com>.
Can a map:mount be inside a map:select like this... We have written a
selector that matches on the host header so we can serve multiple
domains/servers on the same cocoon instance and were just starting to look
at sitemap structure for this.
<map:match pattern="/">
<map:select type="host">
<map:when test="foo.com">
<map:mount uri-prefix="/" src="foo_sitemap.xmap"/>
</map:when>
<map:otherwise>
<map:mount uri-prefix="/" src="fee_sitemap.xmap"/>
</map:otherwise>
</map:select>
</map:match>
do you want me to post the selector?
rgds
CB
----- Original Message -----
From: "Giacomo Pati" <gi...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, March 22, 2001 6:21 AM
Subject: Re: [C2]: Understanding mount
> Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > I am currently playing a little bit with mounting subsitemaps.
> > After a while I got it working now, but I am still wondering
> > what the exact purpose of the attributes uri-prefix and src is.
> >
> > I used the following mount-example from the sitemap draft:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/" src="dist/{1}"/>
> > </map:match>
> >
> > This generates the following source:
> >
> > return sitemapManager.invoke (environment,
> > substitute(listOfLists, "dist/"),
> > substitute(listOfLists, "dist/{1}"), true);
>
> The uri-prefix is the part that should be removed from the request URI.
> The engine will correctly check for a trailing slash (which you may
> write, of course)
>
> The src attribute is where the subsitemap is located. If it ends in a
> slash "sitemap.xmap" is appended to find the sitemap otherwise the src
> value is used. A check-reload attribute can be used to determine if the
> modification date of the subsitemap file should be checked. A mount
> element I use looks like:
>
> <map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
> or
> <map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
> check-reload="no"/>
>
> Giacomo
>
> > The third argument ("substitute(listOfLists, "dist/{1}")") is the
> > source argument for the sitemap handler to load the new sitemap.
> > So if I try to load the resource "dist/hello" the sitemap
> > "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> > "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> > to loaded. And so on.
> >
> > So I assume from this, that the "src" attribute indicates the location
of the subsitemap.
> > This would lead to:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/"
src="dist/subsitemap.xmap"/>
> > </map:match>
> >
> > The "uri-prefix" seems to be the part which has to be removed from the
uri,
> > this means sending the request "dist/welcome" will remove "dist/" from
the
> > uri and only "welcome" is passed to the subsitemap.
> > So I could use
> > <map:match pattern="hallo">
> > <map:generate src="test.xml"/>
> > <map:serialize type="xml"/>
> > </map:match>
> > in the "dist/subsitemap.xmap" to match the request.
> >
> > This example above works fine. Am I using the attributes correcly?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] sitemap
Posted by Giacomo Pati <gi...@apache.org>.
John Morrison wrote:
>
> My (main) sitemap doesn't reload automatically - is there something I need
> to set somewhere?
Are you sure? The sitemap regenerates as a background thread, in the
mean time you'll be served from the old one. As soon as the new sitemap
is available it will be used instead of the old one.
> I'd also like to know what is possible with the sitemap - is there any
> documents which describe what's there and what's intended in the future?
Well, indead we could have used some more docs. You'll find pieces
scattered around in the repository. The original proposal is
xdocs/draft/sitemap-working-draft.xmap and others are in the xdocs.
You'll get html version if you do a build docs (or alike)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2] sitemap
Posted by John Morrison <jo...@ntlworld.com>.
My (main) sitemap doesn't reload automatically - is there something I need
to set somewhere?
I'd also like to know what is possible with the sitemap - is there any
documents which describe what's there and what's intended in the future?
Thanks,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Understanding mount
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
>
> Thank you, Giacomo, for the clearification.
>
> Should we add your explanation to the "sitemap-working-draft.xmap"
> and update the examples there?
What ever you like to document is *very* welcome :)
Giacomo
>
> Carsten
>
> > -----Ursprungliche Nachricht-----
> > Von: giacomo@ynes.de [mailto:giacomo@ynes.de]
> > Gesendet: Donnerstag, 22. Marz 2001 12:21
> > An: cocoon-dev@xml.apache.org
> > Betreff: Re: [C2]: Understanding mount
> >
> >
> >
> > Carsten Ziegeler wrote:
> > >
> > > Hi,
> > >
> > > I am currently playing a little bit with mounting subsitemaps.
> > > After a while I got it working now, but I am still wondering
> > > what the exact purpose of the attributes uri-prefix and src is.
> > >
> > > I used the following mount-example from the sitemap draft:
> > >
> > > <map:match pattern="dist/*">
> > > <map:mount uri-prefix="dist/" src="dist/{1}"/>
> > > </map:match>
> > >
> > > This generates the following source:
> > >
> > > return sitemapManager.invoke (environment,
> > > substitute(listOfLists, "dist/"),
> > > substitute(listOfLists, "dist/{1}"), true);
> >
> > The uri-prefix is the part that should be removed from the request URI.
> > The engine will correctly check for a trailing slash (which you may
> > write, of course)
> >
> > The src attribute is where the subsitemap is located. If it ends in a
> > slash "sitemap.xmap" is appended to find the sitemap otherwise the src
> > value is used. A check-reload attribute can be used to determine if the
> > modification date of the subsitemap file should be checked. A mount
> > element I use looks like:
> >
> > <map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
> > or
> > <map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
> > check-reload="no"/>
> >
> > Giacomo
> >
> > > The third argument ("substitute(listOfLists, "dist/{1}")") is the
> > > source argument for the sitemap handler to load the new sitemap.
> > > So if I try to load the resource "dist/hello" the sitemap
> > > "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> > > "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> > > to loaded. And so on.
> > >
> > > So I assume from this, that the "src" attribute indicates the
> > location of
> > the subsitemap.
> > > This would lead to:
> > >
> > > <map:match pattern="dist/*">
> > > <map:mount uri-prefix="dist/" src
> > ="dist/subsitemap.xmap"/>
> > > </map:match>
> > >
> > > The "uri-prefix" seems to be the part which has to be removed from the
> > uri,
> > > this means sending the request "dist/welcome" will remove "dist/" from
> > the
> > > uri and only "welcome" is passed to the subsitemap.
> > > So I could use
> > > <map:match pattern="hallo">
> > > <map:generate src="test.xml"/>
> > > <map:serialize type="xml"/>
> > > </map:match>
> > > in the "dist/subsitemap.xmap" to match the request.
> > >
> > > This example above works fine. Am I using the attributes correcly?
> > >
> > > Carsten
> > >
> > > Open Source Group sunShine - b:Integrated
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto: cziegeler@sundn.de
> > > ================================================================
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Understanding mount
Posted by Carsten Ziegeler <cz...@sundn.de>.
Thank you, Giacomo, for the clearification.
Should we add your explanation to the "sitemap-working-draft.xmap"
and update the examples there?
Carsten
> -----Ursprungliche Nachricht-----
> Von: giacomo@ynes.de [mailto:giacomo@ynes.de]
> Gesendet: Donnerstag, 22. Marz 2001 12:21
> An: cocoon-dev@xml.apache.org
> Betreff: Re: [C2]: Understanding mount
>
>
>
> Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > I am currently playing a little bit with mounting subsitemaps.
> > After a while I got it working now, but I am still wondering
> > what the exact purpose of the attributes uri-prefix and src is.
> >
> > I used the following mount-example from the sitemap draft:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/" src="dist/{1}"/>
> > </map:match>
> >
> > This generates the following source:
> >
> > return sitemapManager.invoke (environment,
> > substitute(listOfLists, "dist/"),
> > substitute(listOfLists, "dist/{1}"), true);
>
> The uri-prefix is the part that should be removed from the request URI.
> The engine will correctly check for a trailing slash (which you may
> write, of course)
>
> The src attribute is where the subsitemap is located. If it ends in a
> slash "sitemap.xmap" is appended to find the sitemap otherwise the src
> value is used. A check-reload attribute can be used to determine if the
> modification date of the subsitemap file should be checked. A mount
> element I use looks like:
>
> <map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
> or
> <map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
> check-reload="no"/>
>
> Giacomo
>
> > The third argument ("substitute(listOfLists, "dist/{1}")") is the
> > source argument for the sitemap handler to load the new sitemap.
> > So if I try to load the resource "dist/hello" the sitemap
> > "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> > "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> > to loaded. And so on.
> >
> > So I assume from this, that the "src" attribute indicates the
> location of
> the subsitemap.
> > This would lead to:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/" src
> ="dist/subsitemap.xmap"/>
> > </map:match>
> >
> > The "uri-prefix" seems to be the part which has to be removed from the
> uri,
> > this means sending the request "dist/welcome" will remove "dist/" from
> the
> > uri and only "welcome" is passed to the subsitemap.
> > So I could use
> > <map:match pattern="hallo">
> > <map:generate src="test.xml"/>
> > <map:serialize type="xml"/>
> > </map:match>
> > in the "dist/subsitemap.xmap" to match the request.
> >
> > This example above works fine. Am I using the attributes correcly?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi,
>
> I am currently playing a little bit with mounting subsitemaps.
> After a while I got it working now, but I am still wondering
> what the exact purpose of the attributes uri-prefix and src is.
>
> I used the following mount-example from the sitemap draft:
>
> <map:match pattern="dist/*">
> <map:mount uri-prefix="dist/" src="dist/{1}"/>
> </map:match>
>
> This generates the following source:
>
> return sitemapManager.invoke (environment,
> substitute(listOfLists, "dist/"),
> substitute(listOfLists, "dist/{1}"), true);
The uri-prefix is the part that should be removed from the request URI.
The engine will correctly check for a trailing slash (which you may
write, of course)
The src attribute is where the subsitemap is located. If it ends in a
slash "sitemap.xmap" is appended to find the sitemap otherwise the src
value is used. A check-reload attribute can be used to determine if the
modification date of the subsitemap file should be checked. A mount
element I use looks like:
<map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
or
<map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
check-reload="no"/>
Giacomo
> The third argument ("substitute(listOfLists, "dist/{1}")") is the
> source argument for the sitemap handler to load the new sitemap.
> So if I try to load the resource "dist/hello" the sitemap
> "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> to loaded. And so on.
>
> So I assume from this, that the "src" attribute indicates the location of the subsitemap.
> This would lead to:
>
> <map:match pattern="dist/*">
> <map:mount uri-prefix="dist/" src="dist/subsitemap.xmap"/>
> </map:match>
>
> The "uri-prefix" seems to be the part which has to be removed from the uri,
> this means sending the request "dist/welcome" will remove "dist/" from the
> uri and only "welcome" is passed to the subsitemap.
> So I could use
> <map:match pattern="hallo">
> <map:generate src="test.xml"/>
> <map:serialize type="xml"/>
> </map:match>
> in the "dist/subsitemap.xmap" to match the request.
>
> This example above works fine. Am I using the attributes correcly?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org