On Thu, 2005-07-14 at 11:57 +0200, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
> > It seems to me that me may consider using a locationmap for the below
> > stated example and not another protocol.
> >
> > http://marc.theaimsgroup.com/?l=forrest-dev&m=110656404918792&w=2
>
> Would you mind describing the usage of a location map in this context
> in more detail? I've read the proposal / description, but I'm not quite
> sure how this relates to our problem. Maybe you can provide an example?
>
> Thanks!
e.g.
> >>>example 2 (xhtml.css and resources-shared.xmap):
> >>>
> >>> xhtml.css:
> >>>
> >>>@import url(xhtml.parent.css);
> >>
> >> >
> >>
> >>>body {
> >>> margin: 0px;
> >>> padding: 0px;
> >>> background: #F6D897;
> >>> font-size: 90%;
> >>>}
> >>>
> >>> resources-shared.xmap:
> >>> <map:match pattern="*/*/css/*.parent.css">
> >>> <map:read src="parent://resources/shared/css/{3}.css"
> >>>mime-type="text/css" />
> >>> </map:match>
> >>
should become
<map:read src="{lm:resources/shared/css/{3}.css}"
mime-type="text/css" />
Then you can have in your locationmap:
<match pattern="resources/**.css" type="request">
<select type="exists">
<location src="pub/..." />
<location src="parent/" />
<location src="context://lenya/...">
</select>
<location src="fallback://resources..." />
</match>
This way each pub can define their own fallback mechanism *without* inventing
new protocols all the time.
What happen here is that the first existing location will be taken till it
reaches the last <location/> (outside the <select/>).
This last location should be ideally always be found. ;-)
The nice thing is that it can be combined with the fallback mechanism or other
protocols.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
