On Thu, 2006-01-19 at 12:19 +0100, Thorsten Scherler wrote:
> El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
> >
> > Thorsten Scherler wrote:
> > >
> ...
> > > Were else the locationmap let the *user* define the location and the
> > > "to-be-used" fallbacks:
> > > <match pattern="tabs.xml">
> > > <select type="exists">
> > > <location src="{project:content.xdocs}tabs1.xml"/>
> > > <location src="{project:content.xdocs}tabs2.xml"/>
> > > </select>
> > > </match>
> > >
> ...
> > Can you give an example how Lenya's templating hierarchy will look like
> > implemented with the locationmap protocol?
> >
> > Thanks, Felix
>
> I will try but no guarantee that it is correct, since I could not find
> any documentation about fallback in our official docu (hint, hint). ;-)
>
> <match pattern="fallback.**">
> <select type="exists">
> <location src="context://{lenya:pubId}/lenya/**"/>
> <location src="context://{lenya:pubId}/**"/>
> <location src="context://lenya/**"/>
> <location src="context://**"/>
> </select>
> </match>
When you use the locationmap source in the sitemap it would look like
<map:transform src="lm://fallback.xslt/myxsl.xsl"/> ?
What I don't understand so far is how it solves the caching problem this
thread is about.
How does the locationmap tell cocoon that lm://fallback.xslt/myxsl.xsl
is not the same as lm://fallback.xslt/myxsl.xsl if lenya:pubId is
different?
Thanks for a clarification,
Josias
>
> I guess that is the basic rule, right?
>
> The interesting is that a user can extend this default matches
> (see other mail why and when).
>
> salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
