You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by li...@kuhnle.net on 2005/04/08 02:47:43 UTC
Manually specifying a mounted sub sitemap's context
Hi, I suggest a new parameter for map:mount that specifies the context of
the sitemap, i.e. the URL against which all relative URLs are resolved.
Normally, this is the sitemap's own URL, but there are cases where
specifying a different URL makes things easier.
One is the use of generated sitemaps (see excerpt from a root sitemap
below). Here the sub sitemaps are generated from a simple XML file and
mounted with the cocoon:// protocol. With this, the URLs in the sitemap
for "somepath/" are resolved relative to "cocoon://somepath/", but it
would be nice to still have them resolved relative to "somepath/", since
this is were most files used in the sitemap will be. I therefor suggest a
new attribute "context" for "map:mount" that specifies the sitemap
context. I will gladly supply a small patch which does this.
Btw: This example is theoretical, as mounting sitemaps with the "cocon://"
protocol plunges Cocoon into endless recursion, at least with the example
specified below, see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111140628621975&w=2 .
This problem would also be solved.
Regards,
Jochen
<!-- Generate sub sitemaps -->
<map:match pattern="**/sitemap.xmap">
<map:generate type="file" src="{1}/resources.xml"/>
<map:transform type="xslt" src="context:/resources2sitemap.xsl">
<map:parameter name="path" value="{1}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
<!-- Mount sub sitemaps -->
<map:match pattern="*/**">
<map:mount check-reload="yes"
src="cocoon:raw://{1}/sitemap.xmap?cocoon-view=" uri-prefix="{1}"/>
<!-- <map:mount check-reload="yes"
src="cocoon:raw://{1}/sitemap.xmap?cocoon-view=" uri-prefix="{1}"
context="{1}/"/> -->
</map:match>
Re: Manually specifying a mounted sub sitemap's context
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 10 avr. 05, à 17:54, Gianugo Rabellino a écrit :
> ...A check failing with an error message would
> be enough to prevent stupid people like me to try it again in the
> future (even though there will always be the http route...).
And making it a configurable switch with a big warning on it would
allow people to use dynamic sitemaps at their own risk, while making it
clear that it's usually a bad idea.
-Bertrand
Re: Manually specifying a mounted sub sitemap's context
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Gianugo Rabellino wrote:
> On Apr 10, 2005 10:17 PM, Sylvain Wallez <sy...@apache.org> wrote:
>
>>So if we're to enforce something, it should be that a sitemap is a file,
>>or a classpath resource (yes, I have this usecase).
>
>
> Yep. Tricky, though: I sure can imagine sitemaps stored anywhere (why
> not a JSR170 repo? or a webdav server?
See [1]:
<map:mount uri-prefix="xmount"
src="xmldb:xindice-embed:///db/cocoon/sitemap" check-reload="yes"/>
> as long as it's static
> stuff...), and blocking this possibility just to avoid (ab)use of
> possibly dynamic protocols such as cocoon or http could be a bit too
> much. I'd rather go for a big fat warning then...
Vadim
[1]
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/xmldb/samples/sitemap.xmap
Re: Manually specifying a mounted sub sitemap's context
Posted by Sylvain Wallez <sy...@apache.org>.
Gianugo Rabellino wrote:
>On Apr 10, 2005 10:17 PM, Sylvain Wallez <sy...@apache.org> wrote:
>
>
>>So if we're to enforce something, it should be that a sitemap is a file,
>>or a classpath resource (yes, I have this usecase).
>>
>>
>
>Yep. Tricky, though: I sure can imagine sitemaps stored anywhere (why
>not a JSR170 repo? or a webdav server? as long as it's static
>stuff...), and blocking this possibility just to avoid (ab)use of
>possibly dynamic protocols such as cocoon or http could be a bit too
>much. I'd rather go for a big fat warning then...
>
>
Okay, let's open the doors to any protocol. It appears sitemaps already
are read from a wide range of sources :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Manually specifying a mounted sub sitemap's context
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Apr 10, 2005 10:17 PM, Sylvain Wallez <sy...@apache.org> wrote:
> Gianugo Rabellino wrote:
>
> >However, if it's agreed once and for all that
> >dynamic sitemaps are to be considered harmful, so be it and let's
> >enforce it: it slipped through already, and now it doesn't work
> >anymore because of a bug. A check failing with an error message would
> >be enough to prevent stupid people like me to try it again in the
> >future (even though there will always be the http route...).
> >
> >
>
> Well, as long as there is the http route, blocking "cocoon:" will just
> lead people to use an uglier workaround which you just engraved in the
> archives for posterity ;-)
Hey, I wasn't the first one to suggest that ;-)
>
> So if we're to enforce something, it should be that a sitemap is a file,
> or a classpath resource (yes, I have this usecase).
Yep. Tricky, though: I sure can imagine sitemaps stored anywhere (why
not a JSR170 repo? or a webdav server? as long as it's static
stuff...), and blocking this possibility just to avoid (ab)use of
possibly dynamic protocols such as cocoon or http could be a bit too
much. I'd rather go for a big fat warning then...
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: Manually specifying a mounted sub sitemap's context
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Well, as long as there is the http route, blocking "cocoon:" will just
> lead people to use an uglier workaround which you just engraved in the
> archives for posterity ;-)
>
> So if we're to enforce something, it should be that a sitemap is a file,
> or a classpath resource (yes, I have this usecase).
>
And we (and others as well) have the use case to read a sitemap (and all
resources) from webdav which currently works very well. So, I don't see
any real sense in blocking specific protocols while allowing others. Let
the users decide for themselves where they want to have their sitemaps
stored. We can encourage people to use the file system but we shouldn't
force them.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Manually specifying a mounted sub sitemap's context
Posted by Sylvain Wallez <sy...@apache.org>.
Gianugo Rabellino wrote:
>On Apr 10, 2005 4:24 PM, Stefano Mazzocchi <st...@apache.org> wrote:
>
>
>>Sylvain Wallez wrote:
>>
>>
>>>So, although we may accept a new "context" attribute (I'm currently -0.9
>>>for this), I'm -1 for accepting dynamically generated sitemaps.
>>>
>>>
>>I'm -1 as well. (that was easy to guess ;-)
>>
>>
>
>Uhm, first of all I'd say that the "context" attribute could be really
>useful in contexts other than dynamic sitemaps, so I'd welcome that
>addition. WRT dynamic sitemaps, I don't quite have a real opinion, I
>can clearly see how it might lead to abuse, but I also tend to think
>that Cocoon, as a framework, should allow applications built on top of
>it using subsets of functionalities abstracted in high level
>configuration files. However, if it's agreed once and for all that
>dynamic sitemaps are to be considered harmful, so be it and let's
>enforce it: it slipped through already, and now it doesn't work
>anymore because of a bug. A check failing with an error message would
>be enough to prevent stupid people like me to try it again in the
>future (even though there will always be the http route...).
>
>
Well, as long as there is the http route, blocking "cocoon:" will just
lead people to use an uglier workaround which you just engraved in the
archives for posterity ;-)
So if we're to enforce something, it should be that a sitemap is a file,
or a classpath resource (yes, I have this usecase).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Manually specifying a mounted sub sitemap's context
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Apr 10, 2005 4:24 PM, Stefano Mazzocchi <st...@apache.org> wrote:
> Sylvain Wallez wrote:
> > So, although we may accept a new "context" attribute (I'm currently -0.9
> > for this), I'm -1 for accepting dynamically generated sitemaps.
>
> I'm -1 as well. (that was easy to guess ;-)
Uhm, first of all I'd say that the "context" attribute could be really
useful in contexts other than dynamic sitemaps, so I'd welcome that
addition. WRT dynamic sitemaps, I don't quite have a real opinion, I
can clearly see how it might lead to abuse, but I also tend to think
that Cocoon, as a framework, should allow applications built on top of
it using subsets of functionalities abstracted in high level
configuration files. However, if it's agreed once and for all that
dynamic sitemaps are to be considered harmful, so be it and let's
enforce it: it slipped through already, and now it doesn't work
anymore because of a bug. A check failing with an error message would
be enough to prevent stupid people like me to try it again in the
future (even though there will always be the http route...).
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: Manually specifying a mounted sub sitemap's context
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Hi Jochen,
>>
>> your idea sounds good to me. Can you please add a feature request to
>> bugzilla with your patch?
>>
>>
>
> Well, having dynamically generated sitemaps doesn't seem that good to me.
>
> About Gianugo's problem: we had a discussion where it appears the
> sitemap is the by-product of some higher-level XML description, hence
> why he wanted to use "cocoon:".
>
> Now using a pipeline as the sitemap source can have a tremendous cost if
> that pipeline isn't cacheable, and in Gianugo's case I suggested him to
> generate the sitemap on disk when the higher-level description changes,
> which doesn't happen so often.
>
> Cocoon is sometimes too much powerful and people use too much "cocoon:"
> dynamic URLs when other systems would require to dump something on disk,
> and this can lead to overly complex and and very unefficient architectures.
>
> So, although we may accept a new "context" attribute (I'm currently -0.9
> for this), I'm -1 for accepting dynamically generated sitemaps.
I'm -1 as well. (that was easy to guess ;-)
--
Stefano.
Re: Manually specifying a mounted sub sitemap's context
Posted by Antonio Gallardo <ag...@agssa.net>.
On Dom, 10 de Abril de 2005, 15:12, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>
>>On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo:
>>
>>
>>>Sylvain Wallez <sy...@apache.org> wrote on 09.04.2005 20:51:41:
>>>
>>>
>>>>In other words, should it be:
>>>>
>>>> <map:mount src="foo/bar/" context="baz"/>
>>>>and
>>>> <map:sitemap>
>>>>
>>>>or
>>>> <map:mount src="foo/bar/"/>
>>>>and
>>>> <map:sitemap context="baz"/>
>>>>
>>>>
>>>>My feeling favors the second form, as allowing to specify the context
>>>>externally means that understanding what a sitemap does depends on the
>>>>mount statement.
>>>>
>>>>
>>>Agreed, the second form is easier to understand. The first one was just
>>>easier to implement (at least for me), since MountNode.invoke already
>>>resolves the sitemap context. And this was the point where cocoon went
>>>into endless recursion...
>>>
>>>On the other hand, the first form offers one additional feature:
>>> Mounting
>>>the same sitemap twice with different contexts. I just don't know yet if
>>>this is a good idea...
>>>
>>>
>>>
>>
>>I see this as a good idea. I have a lot of literally equals sitemaps that
>>with something like that I can get rid of them by just defining his
>>context.
>>
>>
>
> What do you mean by "literally equals"?
>
> Do they differ because:
> - there is a a slight difference in what they should do (in that case
> what about pass-through mounts?)
> - or because they provide the same pipelines but operate on different
> data?
The second:
they provide the same pipelines but operate on different data.
Building webapps, you have some forms sets (businnes module? [BM]) that
provide basic functionality (create, edit, search) on diferent data
(tables). Perhaps this is our fault, I know I can use a parent sitemap for
that. But we don't see it as a good solution for us, since we want to keep
every BM separated (and independent) of the others. That can allow us to
"move" a defined MB to another application by just copy paste a MB.
Maybe we need to find another solution for that.
Best Regards,
Antonio Gallardo.
Re: Manually specifying a mounted sub sitemap's context
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo:
>
>
>>Sylvain Wallez <sy...@apache.org> wrote on 09.04.2005 20:51:41:
>>
>>
>>>In other words, should it be:
>>>
>>> <map:mount src="foo/bar/" context="baz"/>
>>>and
>>> <map:sitemap>
>>>
>>>or
>>> <map:mount src="foo/bar/"/>
>>>and
>>> <map:sitemap context="baz"/>
>>>
>>>
>>>My feeling favors the second form, as allowing to specify the context
>>>externally means that understanding what a sitemap does depends on the
>>>mount statement.
>>>
>>>
>>Agreed, the second form is easier to understand. The first one was just
>>easier to implement (at least for me), since MountNode.invoke already
>>resolves the sitemap context. And this was the point where cocoon went
>>into endless recursion...
>>
>>On the other hand, the first form offers one additional feature: Mounting
>>the same sitemap twice with different contexts. I just don't know yet if
>>this is a good idea...
>>
>>
>>
>
>I see this as a good idea. I have a lot of literally equals sitemaps that
>with something like that I can get rid of them by just defining his
>context.
>
>
What do you mean by "literally equals"?
Do they differ because:
- there is a a slight difference in what they should do (in that case
what about pass-through mounts?)
- or because they provide the same pipelines but operate on different data?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Manually specifying a mounted sub sitemap's context
Posted by Antonio Gallardo <ag...@agssa.net>.
On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo:
> Sylvain Wallez <sy...@apache.org> wrote on 09.04.2005 20:51:41:
>>
>> In other words, should it be:
>>
>> <map:mount src="foo/bar/" context="baz"/>
>> and
>> <map:sitemap>
>>
>> or
>> <map:mount src="foo/bar/"/>
>> and
>> <map:sitemap context="baz"/>
>>
>>
>> My feeling favors the second form, as allowing to specify the context
>> externally means that understanding what a sitemap does depends on the
>> mount statement.
>
> Agreed, the second form is easier to understand. The first one was just
> easier to implement (at least for me), since MountNode.invoke already
> resolves the sitemap context. And this was the point where cocoon went
> into endless recursion...
>
> On the other hand, the first form offers one additional feature: Mounting
> the same sitemap twice with different contexts. I just don't know yet if
> this is a good idea...
>
I see this as a good idea. I have a lot of literally equals sitemaps that
with something like that I can get rid of them by just defining his
context.
Best Regards,
Antonio Gallardo.
Re: Manually specifying a mounted sub sitemap's context
Posted by Jochen Kuhnle <li...@kuhnle.net>.
Sylvain Wallez <sy...@apache.org> wrote on 09.04.2005 20:51:41:
>
> That being said, there's another issue about the proposed "context"
> attribute: who's responsibility is it to specify on what context will a
> sitemap operate? Is it the <map:mount>'s responsibility or the sitemap's
> own responsibility?
>
> In other words, should it be:
>
> <map:mount src="foo/bar/" context="baz"/>
> and
> <map:sitemap>
>
> or
> <map:mount src="foo/bar/"/>
> and
> <map:sitemap context="baz"/>
>
>
> My feeling favors the second form, as allowing to specify the context
> externally means that understanding what a sitemap does depends on the
> mount statement.
>
Agreed, the second form is easier to understand. The first one was just
easier to implement (at least for me), since MountNode.invoke already
resolves the sitemap context. And this was the point where cocoon went
into endless recursion...
On the other hand, the first form offers one additional feature: Mounting
the same sitemap twice with different contexts. I just don't know yet if
this is a good idea...
> Hmm... same use case as Gianugo. Is it possible for these files to be
> changed directly on the live site, or is this part of some kind of
> deployment operation?
Deployment in this case being "copy file from A to B". Not pretty, but in
this case it is sufficient. No "call sitemap generator" steps that can be
forgotten or need to be automated.
> What you need here is a global variable that can be used as a prefix,
> thus writing <map:generate src="{global:base}/page.jx"/>
>
There are workarounds, but I think having the possibility to use generated
sitemaps (eiter with the context attribute, or a mounting operation that
does not crash), is generally a good thing to have and makes "sitemapping"
easier for the guys maintaining the site. And no-one can use the
"cocoon:"-protocol in the sub-sitemaps if you don't want them to.
After all, in my opinion, sitemaps combine to concerns: The definition of
resource classes ("A dynamic page of type X is generated from JX
templates, run through these transformations, and then serialized as
HTML"), the site developer's task, and the definition of resources and
their properties ("There is a dynamic page called hello.jx, it is
customized for every user, so include the user name in the cache key, and
it also has the following additional traits..."), the site maintainer's
task. Using generated sitemaps lets us separate these concerns.
Regards,
Jochen
Re: Manually specifying a mounted sub sitemap's context
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 9 avr. 05, à 19:21, Sylvain Wallez a écrit :
>
>> ...Cocoon is sometimes too much powerful and people use too much
>> "cocoon:" dynamic URLs when other systems would require to dump
>> something on disk, and this can lead to overly complex and and very
>> unefficient architectures.
>>
>> So, although we may accept a new "context" attribute (I'm currently
>> -0.9 for this), I'm -1 for accepting dynamically generated sitemaps...
>
>
> Hmm...sounds a bit like the arguments against XWindows when it was
> created: at that time most people couldn't afford the system and
> network resources used to run it. But the "processors and networks get
> faster all the time anyway" attitude made XWindows a very long-lasting
> and powerful system.
>
> So, although dynamically generated sitemaps might be risky
> performance-wise today, I don't think we should block them. People
> might find brilliant uses for them - we just have to warn our users
> about potential bottlenecks.
Well, at work we currently have to maintain and evolve a project
(written elsewhere) where people have written a gazillion chained
pipelines with "cocoon:" everywhere where a simple Java class would have
done the job. A nightmare to understand and maintain.
And seeing <map:mount src="cocoon:/blah"/> seems to open dangerous doors
to me...
That being said, there's another issue about the proposed "context"
attribute: who's responsibility is it to specify on what context will a
sitemap operate? Is it the <map:mount>'s responsibility or the sitemap's
own responsibility?
In other words, should it be:
<map:mount src="foo/bar/" context="baz"/>
and
<map:sitemap>
or
<map:mount src="foo/bar/"/>
and
<map:sitemap context="baz"/>
My feeling favors the second form, as allowing to specify the context
externally means that understanding what a sitemap does depends on the
mount statement.
Well, that's right that a sitemap already depends on the mount statement
for component definitions inherited from the parent. But now knowing
what "blah.xml" means in <map:generate src="blah.xml"/> seems really
weird to me...
Maybe I'm just too conservative about this, but this doesn't smell good...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Manually specifying a mounted sub sitemap's context
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 avr. 05, à 19:21, Sylvain Wallez a écrit :
> ...Cocoon is sometimes too much powerful and people use too much
> "cocoon:" dynamic URLs when other systems would require to dump
> something on disk, and this can lead to overly complex and and very
> unefficient architectures.
>
> So, although we may accept a new "context" attribute (I'm currently
> -0.9 for this), I'm -1 for accepting dynamically generated sitemaps...
Hmm...sounds a bit like the arguments against XWindows when it was
created: at that time most people couldn't afford the system and
network resources used to run it. But the "processors and networks get
faster all the time anyway" attitude made XWindows a very long-lasting
and powerful system.
So, although dynamically generated sitemaps might be risky
performance-wise today, I don't think we should block them. People
might find brilliant uses for them - we just have to warn our users
about potential bottlenecks.
-Bertrand
Re: Manually specifying a mounted sub sitemap's context
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> So, although we may accept a new "context" attribute (I'm currently -0.9
> for this), I'm -1 for accepting dynamically generated sitemaps.
>
Hmm, really? And what if I don't use the cocoon protocol but the http
and address Cocoon "externally"? The sitemap is created dynamically as
well. So, if you don't want to accept dynamically generated sitemaps you
have to prevent people from using any other protocol than the file
protocol! Now, as it is possible today, I see no problem with fixing the
problems with using the cocoon protocol for generating a sitemap. But on
the other hand, I currently don't need it...
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Manually specifying a mounted sub sitemap's context
Posted by Sylvain Wallez <sy...@apache.org>.
Jochen Kuhnle wrote:
>Hi Sylvain,
>
>I agree that generated sitemaps are a somewhat more sophisticated use of
>Cocoon. However, I think it is a nice feature to have. My main reason for
>this is that I want to hide the nuts and bolts of sitemaps from site
>maintainers and just want to give them a limited subset (or high-level XML
>description) for the one specific site that is easy to understand and
>maintain. So why not pre-generate it? So no-one ever forgets to do it!
>
Hmm... same use case as Gianugo. Is it possible for these files to be
changed directly on the live site, or is this part of some kind of
deployment operation?
>I found that it is quite efficient to generate the sitemap dynamically.
>Since the sitemap-pipeline is created by a developer who knows more about
>this stuff (including caching) than a maintainer, I think we can assume it
>will be cacheable. Of course optimum support here would be to have the
>map:mount code write "DANGER! Your sitemap pipeline is not cacheable" to
>the log, but I don't think this is necessary.
>
>In addition, I can think of use cases where specifiable contexts might
>come in handy even for "normal" sitemaps. One is that you maybe want to
>differentiate access rights to sitemaps from access rights to content.
>With a specifiable context, you could move all sitemaps into a special
>sitemap-directory (or tree), separate from the content, and still avoid
>ugly directory traversal prefixes to content files (<map:generate
>type="jx" src="../../../path/to/the/content/directory/page.jx"/>). You get
>"nicer" sitemaps, and you just have to set file permissions on two
>directories (the sitemap and the site directory) instead of each and every
>file.
>
>
What you need here is a global variable that can be used as a prefix,
thus writing <map:generate src="{global:base}/page.jx"/>
And if you find it too verbose, what you need is the sitemap to be able
to define it's own context (i.e. <map:sitemap
context="../../../path/to/the/content/directory">, see my previous post)
and not have this context be defined externally.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Manually specifying a mounted sub sitemap's context
Posted by Ralph Goers <Ra...@dslextreme.com>.
Stefano Mazzocchi wrote:
> Yes, indeed.
>
> I mean, look at you: sitemap via webdav? via JCR170? what's next?
> SOAP? what about describing the sitemap in LDAP directly, you could
> use netinfo to edit it! hmmm, no, wait, what about sitemap via email?
> you post the sitemap attached to an email to a mailing list and then
> the last becomes the published one?
>
Actually, I'm kind of surprised at your response to this one. Storing
the sitemap in a CMS makes perfect sense to me since logically it is
perceived as nothing more than a "versioned" file system. This would
allow site administrators to modify the application without having to
rebuild or redeploy the web app while automatically maintaining it is a
version control system. However, to be honest, I'd only use this
during development. In production I'd force the CMS to publish the
sitemap to the file system to perform better.
Ironically, this is exactly what we do (retrieve from CMS in "work" mode
and from files in "live" mode) with all our web content, including the
portal layouts. Our sitemaps are static however.
Ralph
Re: Manually specifying a mounted sub sitemap's context
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 12 avr. 05, à 15:09, Gianugo Rabellino a écrit :
> ...<select xpath="/document/[@type='something']">
> <validate src="repo://some-schema.xsd" log="warning"/>
> <validate src="repo://some-schematron.error" log="error"/>
> </select>...
IMHO a perfect example of why dynamically generated sitemaps can be
useful *in some very specific cases* and allow people to invent new and
wonderful ways of using Cocoon.
Maybe something like
<map:pipeline allow-dynamic-sitemaps="true">
Would be good, in the sense of "Separate policy from mechanism".
(I know: allow-dynamic-sitemaps is verbose ;-)
-Bertrand
Re: Manually specifying a mounted sub sitemap's context
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
> On Apr 11, 2005 5:44 PM, Stefano Mazzocchi <st...@apache.org> wrote:
>
>>I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
>>what about describing the sitemap in LDAP directly, you could use
>>netinfo to edit it! hmmm, no, wait, what about sitemap via email? you
>>post the sitemap attached to an email to a mailing list and then the
>>last becomes the published one?
>
>
> I'll take the offensive bit out, enjoy the ironic part and comment on
> the beef. I have always considered Cocoon as a *framework*. Frameworks
> are supposed to be horizontal foundations on which vertical layers can
> be built. With Cocoon you can build an e-commerce site, a CMS, a
> banking application or an XML middleware: to do so you use the "tools
> of the trade", sitemaps, pipelines and all the yadda-yadda. However,
> it very possible (and actually likely) that application's high-level
> business rules don't quite map to a Cocoon sitemap because either a)
> all they need is a small subset of the sitemap crop or b) the semantic
> equivalence is poor.
>
> Now, let me make you a concrete example: we are currently building an
> XML validation server which is supposed to be able to solve a few
> issues in the XML validation world for some B2B humpfko. Basically
> what we do is provide a sequence of validation steps where you can
> define an arbitrary set of schema, relaxng, schematron and the like.
> Every validation step is logged separately so that you can spot
> problems in the incoming flow, This is clearly a pipeline and Cocoon
> is - to me - the right tool for the job. However, this tool has to be
> administered day in day out from non Cocoon people, so compare this:
>
> <map:match type="xpath" pattern="/document/[@type='something']">
> <map:generate type="stream"/>
> <map:transform type="msv" src="repo://some-schema.xsd"/>
> <map:transform type="mylogger">
> <map:parameter name="level" value="warning"/>
> </map:transform>
> <map:transform type="schematron" src="repo://some-schematron.sch"/>
> <map:transform type="mylogger">
> <map:parameter name="level" value="error"/>
> </map:transform>
> <map:serialize type="xml"/>
> </map:match>
>
> (and consider that this is hidden within the whole sitemap shabang,
> with components, resources, views and whatever)
>
> to this:
>
> <select xpath="/document/[@type='something']">
> <validate src="repo://some-schema.xsd" log="warning"/>
> <validate src="repo://some-schematron.error" log="error"/>
> </select>
>
> If you were the one having to maintain some 500-ish of these
> statements, which format would you prefer? Heck, even I,
> notwhitstanding my Cocoon experience, would go for the second option -
> also considering how easy it would be to GUI-fy that format.
>
> Now, the second option can be clearly translated into an equivalent
> sitemap by means of an almost braindead xslt. And whether it can be
> disputed whether such a sitemap should be generated dynamically or in
> an offline way, I don't think that favoring a more domain-oriented
> vocabulary for a specific application can be FS. Not, for that matter,
> is FS willing to persist such configuration files in places other than
> the local filesystem (think clusters). I fail to see how webapp
> componentization and blocks are going to solve issues like this one.
I wonder how long is going to take for somebody to introduce <if> in
there. ;-)
--
Stefano.
Re: Manually specifying a mounted sub sitemap's context
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Apr 11, 2005 5:44 PM, Stefano Mazzocchi <st...@apache.org> wrote:
> I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
> what about describing the sitemap in LDAP directly, you could use
> netinfo to edit it! hmmm, no, wait, what about sitemap via email? you
> post the sitemap attached to an email to a mailing list and then the
> last becomes the published one?
I'll take the offensive bit out, enjoy the ironic part and comment on
the beef. I have always considered Cocoon as a *framework*. Frameworks
are supposed to be horizontal foundations on which vertical layers can
be built. With Cocoon you can build an e-commerce site, a CMS, a
banking application or an XML middleware: to do so you use the "tools
of the trade", sitemaps, pipelines and all the yadda-yadda. However,
it very possible (and actually likely) that application's high-level
business rules don't quite map to a Cocoon sitemap because either a)
all they need is a small subset of the sitemap crop or b) the semantic
equivalence is poor.
Now, let me make you a concrete example: we are currently building an
XML validation server which is supposed to be able to solve a few
issues in the XML validation world for some B2B humpfko. Basically
what we do is provide a sequence of validation steps where you can
define an arbitrary set of schema, relaxng, schematron and the like.
Every validation step is logged separately so that you can spot
problems in the incoming flow, This is clearly a pipeline and Cocoon
is - to me - the right tool for the job. However, this tool has to be
administered day in day out from non Cocoon people, so compare this:
<map:match type="xpath" pattern="/document/[@type='something']">
<map:generate type="stream"/>
<map:transform type="msv" src="repo://some-schema.xsd"/>
<map:transform type="mylogger">
<map:parameter name="level" value="warning"/>
</map:transform>
<map:transform type="schematron" src="repo://some-schematron.sch"/>
<map:transform type="mylogger">
<map:parameter name="level" value="error"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
(and consider that this is hidden within the whole sitemap shabang,
with components, resources, views and whatever)
to this:
<select xpath="/document/[@type='something']">
<validate src="repo://some-schema.xsd" log="warning"/>
<validate src="repo://some-schematron.error" log="error"/>
</select>
If you were the one having to maintain some 500-ish of these
statements, which format would you prefer? Heck, even I,
notwhitstanding my Cocoon experience, would go for the second option -
also considering how easy it would be to GUI-fy that format.
Now, the second option can be clearly translated into an equivalent
sitemap by means of an almost braindead xslt. And whether it can be
disputed whether such a sitemap should be generated dynamically or in
an offline way, I don't think that favoring a more domain-oriented
vocabulary for a specific application can be FS. Not, for that matter,
is FS willing to persist such configuration files in places other than
the local filesystem (think clusters). I fail to see how webapp
componentization and blocks are going to solve issues like this one.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: Manually specifying a mounted sub sitemap's context
Posted by Stefano Mazzocchi <st...@apache.org>.
Reinhard Poetz wrote:
> Stefano Mazzocchi wrote:
>
>> So, if you think there is a functionality missing in the sitemap,
>> propose a way to fix it, don't propose a way for you to route around it.
>
>
> I agree with Stefano. And AFAIU the problem that has led to this
> discussion will go away with real blocks and virtual sitemap components:
>
> <quote name="Jochen">
> My main reason for
> this is that I want to hide the nuts and bolts of sitemaps from site
> maintainers and just want to give them a limited subset (or high-level XML
> description) for the one specific site that is easy to understand and
> maintain. So why not pre-generate it?
> </qoute>
Yes, indeed.
I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
what about describing the sitemap in LDAP directly, you could use
netinfo to edit it! hmmm, no, wait, what about sitemap via email? you
post the sitemap attached to an email to a mailing list and then the
last becomes the published one?
FS.
This sitemap dynamic loading is a workaround for the inability for
cocoon to componentize the webapp space and the work on blocks (yes,
it's happening, as you can see from Reinhard's and Daniel's commits!).
My -1 remains.
--
Stefano.
Re: Manually specifying a mounted sub sitemap's context
Posted by Reinhard Poetz <re...@apache.org>.
Stefano Mazzocchi wrote:
> So, if you think there is a functionality missing in the sitemap,
> propose a way to fix it, don't propose a way for you to route around it.
I agree with Stefano. And AFAIU the problem that has led to this discussion will
go away with real blocks and virtual sitemap components:
<quote name="Jochen">
My main reason for
this is that I want to hide the nuts and bolts of sitemaps from site
maintainers and just want to give them a limited subset (or high-level XML
description) for the one specific site that is easy to understand and
maintain. So why not pre-generate it?
</qoute>
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Manually specifying a mounted sub sitemap's context
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mar, 12 de Abril de 2005, 5:23, Jochen Kuhnle dijo:
> Stefano Mazzocchi <st...@apache.org> wrote on 11.04.2005 17:57:54:
>
>> Upayavira wrote:
>> > FWIW, stefano's -1 was for dynamic sitemaps, not for a context
> attribute
>> > to map:mount.
>>
>> correct.
>>
>> --
>> Stefano.
>>
>
> So do I enter the context patch into bugzilla now?
:-) Yep.
Best Regards,
Antonio Gallardo
Re: Manually specifying a mounted sub sitemap's context
Posted by Joerg Heinicke <jo...@gmx.de>.
On 12.04.2005 12:23, Jochen Kuhnle wrote:
> So do I enter the context patch into bugzilla now?
What's the progress on this? Though I found the bug [1] I can not read
it, bugzilla has problems at the moment.
Joerg
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=34781
Re: Manually specifying a mounted sub sitemap's context
Posted by Jochen Kuhnle <li...@kuhnle.net>.
Stefano Mazzocchi <st...@apache.org> wrote on 11.04.2005 17:57:54:
> Upayavira wrote:
> > FWIW, stefano's -1 was for dynamic sitemaps, not for a context
attribute
> > to map:mount.
>
> correct.
>
> --
> Stefano.
>
So do I enter the context patch into bugzilla now?
Regards,
Jochen
Re: Manually specifying a mounted sub sitemap's context
Posted by Stefano Mazzocchi <st...@apache.org>.
Upayavira wrote:
> Antonio Gallardo wrote:
>
>> On Lun, 11 de Abril de 2005, 8:09, Vadim Gritsenko dijo:
>>
>>> Jochen Kuhnle wrote:
>>>
>>>> <map:mount src="usersitemap.xmap" prefix="~{1}/"
>>>> context="/home/{1}/pages/"/>
>>>
>>>
>>> I'm +1 for this form; and IIUC Antonio has similar use case: same
>>> sitemap
>>> for
>>> different directories.
>>
>>
>>
>> Yep. I have thesame sitemap for diferent dirs.
>>
>> But what to do? AFAIK, we cannot implement that because the Stefano's
>> -1? :-(
>
>
> FWIW, stefano's -1 was for dynamic sitemaps, not for a context attribute
> to map:mount.
correct.
--
Stefano.
Re: Manually specifying a mounted sub sitemap's context
Posted by Upayavira <uv...@upaya.co.uk>.
Antonio Gallardo wrote:
> On Lun, 11 de Abril de 2005, 8:09, Vadim Gritsenko dijo:
>
>>Jochen Kuhnle wrote:
>>
>>><map:mount src="usersitemap.xmap" prefix="~{1}/"
>>>context="/home/{1}/pages/"/>
>>
>>I'm +1 for this form; and IIUC Antonio has similar use case: same sitemap
>>for
>>different directories.
>
>
> Yep. I have thesame sitemap for diferent dirs.
>
> But what to do? AFAIK, we cannot implement that because the Stefano's -1? :-(
FWIW, stefano's -1 was for dynamic sitemaps, not for a context attribute
to map:mount.
Regards, Upayavira
Re: Manually specifying a mounted sub sitemap's context
Posted by Antonio Gallardo <ag...@agssa.net>.
On Lun, 11 de Abril de 2005, 8:09, Vadim Gritsenko dijo:
> Jochen Kuhnle wrote:
>> <map:mount src="usersitemap.xmap" prefix="~{1}/"
>> context="/home/{1}/pages/"/>
>
> I'm +1 for this form; and IIUC Antonio has similar use case: same sitemap
> for
> different directories.
Yep. I have thesame sitemap for diferent dirs.
But what to do? AFAIK, we cannot implement that because the Stefano's -1? :-(
Best Regards,
Antonio Gallardo
Re: Manually specifying a mounted sub sitemap's context
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jochen Kuhnle wrote:
> <map:mount src="usersitemap.xmap" prefix="~{1}/"
> context="/home/{1}/pages/"/>
I'm +1 for this form; and IIUC Antonio has similar use case: same sitemap for
different directories.
Vadim
Re: Manually specifying a mounted sub sitemap's context
Posted by Jochen Kuhnle <li...@kuhnle.net>.
And I thought nobody would care about this small change :) Since Cocoon is
all about access to many sources and generated XML, I as a developer am
actually surprised that what works with URLs everywhere does not work with
sitemap URLs. I think this is inconsistent, and when writing my initial
posting I actually thought I'd found a bug...
Stefano Mazzocchi <st...@apache.org> wrote on 10.04.2005 16:32:36:
>
> here is my rationale for the my everlasting -1 on a dynamic sitemap
> (this -1 is there since 2000, and I'm not changing it).
>
> the sitemap is one of the key functionalities of cocoon, having it
> dynamic would allow people to avoid fighting for a functionality and
> work around it on their own.
>
They do this anyway. Making it harder to work around only will lead to
uglier workarounds. Cocoon already is open to many kinds of "abuse" and
workarounds. For the abuse category, see the "cocoon:"-nightmare-sitemap
that Sylvain mentioned (it's not generated, I suppose). For the workaround
category see Lenya's page envelope action, which delegates its work back
to the sitemap, a concept that I find harder to understand and use than
dynamically generated sitemaps. After all, you can allow access to the
generated sitemap in debug mode, and then you have an
all-in-one-place-sitemap-language-only-straighforward description of your
site.
>
> if you feel you need dynamic sitemaps, is because the sitemap is not
> powerful enough for what you want to achieve. If that is the case *I*
> want to fix the sitemap, rather than allow you to branch off and patch
> it on your own.
>
> Sure, it takes longer and sure, it might not be exactly what you wanted,
> but it will do the job, meet the requirements and make *everybody*
advance.
>
> So, if you think there is a functionality missing in the sitemap,
> propose a way to fix it, don't propose a way for you to route around it.
>
With dynamic sitemaps, I actually want to restrict the power of sitemaps
to a certain subset. I agree that there may be better solutions ahead, but
they are not here yet, and as you stated, they will take longer. Only, I'd
like to have this feature sooner, so why not put it in there, since it
will do only harm to people abusing it against our excplicit warning, and
there seem to be other people that can put it to good use. Later, after we
have developed a better solution, users can switch to it.
In any case, we will not be able to prevent abuse anyway, see the http:
"workaround". And if we disallow the "cocoon:" protocol, people still can
easily write a "get-around-this:" pseudo protocol.
Having generated sitemaps is a generic solution. We don't have to extend
the sitemap language to achieve a goal that we have not yet anticipated in
the sitmap language. On the other hand, sitemap language extensions are
always solutions for one specific kind of problem. If I see that my
sitemap XSLTs do one specific thing most of the time, I of course will try
to propose a better solution and work on it, too. By then, I will have a
good understanding of the problem and might be able to develop a good
solution. Until then, my cocoon application works without ugly
workarounds.
So what now? Basically three questions were discussed and need answering:
1. Should other protocols than "file:" for sitemaps be disallowed?
2. Should the "cocoon:" protocol be fixed so sitemaps can be generated?
3. Should sitemaps be mountable with a specified context?
Of course since I have written the original proposal, I am highly
opiniated towards yes :)
re 1. Postings have shown that people already use other protocols for
sitemaps. Sylvain needs resources, Carsten needs WebDAV, Gianugo has
suggested JSR170 repos, I've seen Xindice and even protocol extensions
like Lotus Domino access (btw: Is the ASF interested in a DominoGenerator?
I happen to have one...). I have the feeling that if we discontinue this
support, we'll see a lot of "why did the xy: protocol stop working" on
cocoon-users. It's already out there, we use it, and I think there is no
reason to take that away.
re 2. Generated sitemaps have found very strong opposition. The arguments
against them were that it is better to make sitemaps more powerful than to
generate them, that there are possible ways to abuse this feature, that
there are security and (if the sitemap is not from a cacheable pipeline)
performance issues. Performance is an implementation issue that can be
solved. Since generated sitemaps can do no more harm than normal ones, I
don't see why they should become a security issue. Abuse cannot be
prevented. This leaves the "more powerful sitemaps" argument. If the
sitemap++ does the job, developers will use it, if not, they can still
implement a new feature with generation. So why not let the users choose?
re 3. The context question has met less resistance. Most of the discussion
has been about the valid point where to put it, in the mount command or in
the mounted sitemap, but this is an implementation detail. Since the
change is fully upwards compatible, I can see no harm. Of course, there
are other solutions for the mentioned problems, but I think specifying the
context is a good solution for some of them. For example, if I want to
mount user directories, but have the sitemap out of reach of the users, it
seems like a good solution to me to do
<map:mount src="usersitemap.xmap" prefix="~joe/"
context="/home/joe/pages/"/>
<map:mount src="usersitemap.xmap" prefix="~jim/"
context="/home/jim/myweb/"/>
Regards,
Jochen
Re: Manually specifying a mounted sub sitemap's context
Posted by Stefano Mazzocchi <st...@apache.org>.
Jochen Kuhnle wrote:
> Hi Sylvain,
>
> I agree that generated sitemaps are a somewhat more sophisticated use of
> Cocoon. However, I think it is a nice feature to have. My main reason for
> this is that I want to hide the nuts and bolts of sitemaps from site
> maintainers and just want to give them a limited subset (or high-level XML
> description) for the one specific site that is easy to understand and
> maintain. So why not pre-generate it? So no-one ever forgets to do it! I
> found that it is quite efficient to generate the sitemap dynamically.
> Since the sitemap-pipeline is created by a developer who knows more about
> this stuff (including caching) than a maintainer, I think we can assume it
> will be cacheable. Of course optimum support here would be to have the
> map:mount code write "DANGER! Your sitemap pipeline is not cacheable" to
> the log, but I don't think this is necessary.
>
> In addition, I can think of use cases where specifiable contexts might
> come in handy even for "normal" sitemaps. One is that you maybe want to
> differentiate access rights to sitemaps from access rights to content.
> With a specifiable context, you could move all sitemaps into a special
> sitemap-directory (or tree), separate from the content, and still avoid
> ugly directory traversal prefixes to content files (<map:generate
> type="jx" src="../../../path/to/the/content/directory/page.jx"/>). You get
> "nicer" sitemaps, and you just have to set file permissions on two
> directories (the sitemap and the site directory) instead of each and every
> file.
here is my rationale for the my everlasting -1 on a dynamic sitemap
(this -1 is there since 2000, and I'm not changing it).
the sitemap is one of the key functionalities of cocoon, having it
dynamic would allow people to avoid fighting for a functionality and
work around it on their own.
if you feel you need dynamic sitemaps, is because the sitemap is not
powerful enough for what you want to achieve. If that is the case *I*
want to fix the sitemap, rather than allow you to branch off and patch
it on your own.
Sure, it takes longer and sure, it might not be exactly what you wanted,
but it will do the job, meet the requirements and make *everybody* advance.
Example: virtual pipeline components were introduced to solve some
pipeline reusability issues, if we had dynamic sitemaps, people would
have worked around that problem with a bunch of (unreusable for others!)
XSLT.
So, if you think there is a functionality missing in the sitemap,
propose a way to fix it, don't propose a way for you to route around it.
--
Stefano.
Re: Manually specifying a mounted sub sitemap's context
Posted by Jochen Kuhnle <li...@kuhnle.net>.
Hi Sylvain,
I agree that generated sitemaps are a somewhat more sophisticated use of
Cocoon. However, I think it is a nice feature to have. My main reason for
this is that I want to hide the nuts and bolts of sitemaps from site
maintainers and just want to give them a limited subset (or high-level XML
description) for the one specific site that is easy to understand and
maintain. So why not pre-generate it? So no-one ever forgets to do it! I
found that it is quite efficient to generate the sitemap dynamically.
Since the sitemap-pipeline is created by a developer who knows more about
this stuff (including caching) than a maintainer, I think we can assume it
will be cacheable. Of course optimum support here would be to have the
map:mount code write "DANGER! Your sitemap pipeline is not cacheable" to
the log, but I don't think this is necessary.
In addition, I can think of use cases where specifiable contexts might
come in handy even for "normal" sitemaps. One is that you maybe want to
differentiate access rights to sitemaps from access rights to content.
With a specifiable context, you could move all sitemaps into a special
sitemap-directory (or tree), separate from the content, and still avoid
ugly directory traversal prefixes to content files (<map:generate
type="jx" src="../../../path/to/the/content/directory/page.jx"/>). You get
"nicer" sitemaps, and you just have to set file permissions on two
directories (the sitemap and the site directory) instead of each and every
file.
Regards,
Jochen
Sylvain Wallez <sy...@apache.org>
09.04.2005 19:21
Please respond to
dev@cocoon.apache.org
To
dev@cocoon.apache.org
cc
Subject
Re: Manually specifying a mounted sub sitemap's context
Carsten Ziegeler wrote:
>Hi Jochen,
>
>your idea sounds good to me. Can you please add a feature request to
>bugzilla with your patch?
>
>
Well, having dynamically generated sitemaps doesn't seem that good to me.
About Gianugo's problem: we had a discussion where it appears the
sitemap is the by-product of some higher-level XML description, hence
why he wanted to use "cocoon:".
Now using a pipeline as the sitemap source can have a tremendous cost if
that pipeline isn't cacheable, and in Gianugo's case I suggested him to
generate the sitemap on disk when the higher-level description changes,
which doesn't happen so often.
Cocoon is sometimes too much powerful and people use too much "cocoon:"
dynamic URLs when other systems would require to dump something on disk,
and this can lead to overly complex and and very unefficient
architectures.
So, although we may accept a new "context" attribute (I'm currently -0.9
for this), I'm -1 for accepting dynamically generated sitemaps.
Jochen, can you elaborate on your use case?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Manually specifying a mounted sub sitemap's context
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Hi Jochen,
>
>your idea sounds good to me. Can you please add a feature request to
>bugzilla with your patch?
>
>
Well, having dynamically generated sitemaps doesn't seem that good to me.
About Gianugo's problem: we had a discussion where it appears the
sitemap is the by-product of some higher-level XML description, hence
why he wanted to use "cocoon:".
Now using a pipeline as the sitemap source can have a tremendous cost if
that pipeline isn't cacheable, and in Gianugo's case I suggested him to
generate the sitemap on disk when the higher-level description changes,
which doesn't happen so often.
Cocoon is sometimes too much powerful and people use too much "cocoon:"
dynamic URLs when other systems would require to dump something on disk,
and this can lead to overly complex and and very unefficient architectures.
So, although we may accept a new "context" attribute (I'm currently -0.9
for this), I'm -1 for accepting dynamically generated sitemaps.
Jochen, can you elaborate on your use case?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Manually specifying a mounted sub sitemap's context
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Jochen,
your idea sounds good to me. Can you please add a feature request to
bugzilla with your patch?
Thanks
Carsten
lists@kuhnle.net wrote:
> Hi, I suggest a new parameter for map:mount that specifies the context of
> the sitemap, i.e. the URL against which all relative URLs are resolved.
> Normally, this is the sitemap's own URL, but there are cases where
> specifying a different URL makes things easier.
>
> One is the use of generated sitemaps (see excerpt from a root sitemap
> below). Here the sub sitemaps are generated from a simple XML file and
> mounted with the cocoon:// protocol. With this, the URLs in the sitemap
> for "somepath/" are resolved relative to "cocoon://somepath/", but it
> would be nice to still have them resolved relative to "somepath/", since
> this is were most files used in the sitemap will be. I therefor suggest a
> new attribute "context" for "map:mount" that specifies the sitemap
> context. I will gladly supply a small patch which does this.
>
> Btw: This example is theoretical, as mounting sitemaps with the "cocon://"
> protocol plunges Cocoon into endless recursion, at least with the example
> specified below, see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111140628621975&w=2 .
> This problem would also be solved.
>
> Regards,
> Jochen
>
> <!-- Generate sub sitemaps -->
> <map:match pattern="**/sitemap.xmap">
> <map:generate type="file" src="{1}/resources.xml"/>
> <map:transform type="xslt" src="context:/resources2sitemap.xsl">
> <map:parameter name="path" value="{1}"/>
> </map:transform>
> <map:serialize type="xml"/>
> </map:match>
> <!-- Mount sub sitemaps -->
> <map:match pattern="*/**">
> <map:mount check-reload="yes"
> src="cocoon:raw://{1}/sitemap.xmap?cocoon-view=" uri-prefix="{1}"/>
> <!-- <map:mount check-reload="yes"
> src="cocoon:raw://{1}/sitemap.xmap?cocoon-view=" uri-prefix="{1}"
> context="{1}/"/> -->
> </map:match>
>
>
>
>
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/