forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: (Re: Q: Images-Cascade in Resources.xmap)
Date Thu, 20 Apr 2006 09:40:38 GMT






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.

So an imagefile that is accidentally dropped in such a directory would
be used instead of the one in the proper location.

That doesn't seem predictable.

> 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 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.


> and adds loads of processing to each request.

Why is that?

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

Pls help me understand that part.

--
Ferdinand Soethe


Mime
View raw message