forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: (Re: Q: Images-Cascade in Resources.xmap)
Date Thu, 20 Apr 2006 09:51:35 GMT
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>>The official documented approaches are predictable.
> Are they? Take this for example:
>    <map:when test="{project:content.xdocs}/{1}/images/{2}.{3}">
>       <map:read src="{project:content.xdocs}/{1}/images/{2}.{3}" mime-type="image/{3}"
>    </map:when>
>    <map:when test="resources/images/{2}.{3}">
>       <map:read src="resources/images/{2}.{3}" mime-type="image/{3}" />
>    </map:when>
> The way I read that, the legacy support for images in a path below
> xdocs that has images in it is always supported and actually takes
> precedence over the currently documented solution.

Oh. I had assumed that the precedence order is what appears in the docs. 
As you say, it *should* be.

>>In my own mind I envision a version 1.0 of Forrest that removes all this
>>potential confusion. It is one reason why I wanted the locationmap in 
>>use. We can deprecate all the old legacy locations and place them in a
>>special "deprecated-locationmap". Then when we write the upgrade 
>>instructions for version 0.x to 1.0 we can say "you should restructure
>>your source files to conform to the standard Forrest structure, or you
>>can create a custom locationmap to support your own structure, or you 
>>can use the deprecated-locationmap to just have things work"
> That was actually the second solution I had in mind. But it doesn't
> really work well with different usage patterns because we would have
> to support a number of different locationsmap-alternatives
> permanently. That seems not only cumbersome but also very error prone.

Why would we support numerous locationmaps? Wouldn't we have the one 
"official" locationmap, this would implement the recommended file 
structure. That's it. We would need to document how to support legacy 
locations, but that would be all wouldn't it?

>>>Why not define these patterns and put them as settings into Forrest
>>>properties. Use switches to support these patterns in the sitemap so
>>>that each usage-patterns has just one predictable behavior.
>>-1 to doing it in the sitemap. That is what the locationmap is for.
>>Adding switches and properties just makes the config files really 
> I disagree. The easiest part of configuring Forrest is to change
> properties in forrest-properties or skinconfig.xml if they are well
> documented.

Well, as Thorsten said, we could use to define 
the entries in the locationmap. This way power users still get to do it 
my way and basic users get to edit a simple properties file. But...

>>and adds loads of processing to each request.
> Why is that?

Because you have to resolve the property each time that part of the 
sitemap is processed, even if the document is in the cache. This is 
because you need the properties to test the cache validity.

> I would think that looking up a file in three different directories
> would take a lot longer than evaluation the setting of a switch.

Yes, which is why we should:

a) ensure the first location is the most likely one (i.e. the default)


b) remove legacy locations so there is only a single place to look


View raw message