Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 20 Apr 2006 11:40:38 +0200
From: Ferdinand Soethe <ferdinand@apache.org>
Message-ID: <1566318187.20060420114038@soethe.net>
To: dev@forrest.apache.org
Subject: Re: (Re: Q: Images-Cascade in Resources.xmap)
In-Reply-To: <44474C50.5070401@apache.org>
References: <1512182280.20060419133155@soethe.net>
 <44468106.8030102@apache.org> <113692083.20060419214055@soethe.net>
 <44469632.6050809@apache.org> <932679752.20060420100050@soethe.net>
 <444742C5.2000507@apache.org> <705230095.20060420104049@soethe.net>
 <44474C50.5070401@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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