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
confusing
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 forrest.properties.xml 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)
and/or
b) remove legacy locations so there is only a single place to look
Ross
