matching order for image resources

[Tim Williams <wi...@gmail.com>]

I'm struggling determining whether the matching order of images can be
different from xml specifically with respect to locationmaps.  Should
images *always* resolve through locationmaps as a last resort the same
as xml?    For example, the "images/**.*" match currently uses
otherwise to match to an apparent backward compatibility set of
images.  It seems to make sense in these cases that locationmap
resolved images would resolve in a higher priority than the current
otherwise.  I've trimmed down an example below to show only the
current matching order.  Thoughts?
--tim

         <map:match pattern="images/**.*">
            <map:select type="exists">
               <map:when test="{project:content.xdocs}/images/{1}.{2}">
               <map:when test="resources/images/{1}.{2}">
               <map:when test="{project:resources.images}/{1}.{2}">
  	      <map:when test="{lm:/images/{1}.{2}}">
	      <map:otherwise>
					  <!-- needed for compatibility for the standard resources/images
that are now
							 in the common skin -->
					  <map:call resource="skin-read">
						 <map:parameter name="path" value="images" />
						 <map:parameter name="name" value="{1}" />
						 <map:parameter name="ext" value="{2}" />
						 <map:parameter name="mime-type" value="image/{2}" />
					  </map:call>								
              </map:otherwise>
            </map:select>
         </map:match>

Re: matching order for image resources

[Nicola Ken Barozzi <ni...@apache.org>]

Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
> 
>> Tim Williams wrote:
>>
>>> I'm struggling determining whether the matching order of images can be
>>> different from xml specifically with respect to locationmaps.  Should
>>> images *always* resolve through locationmaps as a last resort the same
>>> as xml?   
>>
>> We should have two locationmaps: Forrest's and the user's.
>> The user's takes precedence on Forrest's.
> 
> I'd like to avoid a Forrest locationmap at this stage.

I have no problem with this.

...
> To be honest, I'm not yet convinced we need a Forrest locationmap. I 
> think this will be the subject of quite some dscussion, but I'd rather 
> enter the discussion once we have done plenty of experiments with a user 
> locationmap.

No problem. You will see the value when will try to refactor the 
image-svg-png-etc stuff, that is full of redundancy. The locationmap can 
greatly improve the code.

>>> For example, the "images/**.*" match currently uses
>>> otherwise to match to an apparent backward compatibility set of
>>> images.  It seems to make sense in these cases that locationmap
>>> resolved images would resolve in a higher priority than the current
>>> otherwise.  
> 
> Given that the test for the existence of a resource in the users 
> locationmap may be expensive, i.e. it may request a remote resource, I 
> think it should be the last test in the chain.
> 
> When we come to refactor the sitemaps either with a Forrest locationmap 
> or for the 1.0 release we can reconsider this decision.

It's not that important ATM, I concede.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: matching order for image resources

[Ross Gardler <rg...@apache.org>]

Nicola Ken Barozzi wrote:
> Tim Williams wrote:
> 
>> I'm struggling determining whether the matching order of images can be
>> different from xml specifically with respect to locationmaps.  Should
>> images *always* resolve through locationmaps as a last resort the same
>> as xml?   
> 
> 
> We should have two locationmaps: Forrest's and the user's.
> The user's takes precedence on Forrest's.

I'd like to avoid a Forrest locationmap at this stage. I do think there 
is value in one, but I'd rather get the user locationmap working first, 
this is what adds the immediate value to the user. The Forrest one only 
really adds value to us devs and I'm not yet sure how far the Forrest 
locationmap should go, that is I am not sure yet, how much of the logic 
should be moved out of the sitemap into the locationmap. We need to be 
careful not to simply create *another* config file.

To be honest, I'm not yet convinced we need a Forrest locationmap. I 
think this will be the subject of quite some dscussion, but I'd rather 
enter the discussion once we have done plenty of experiments with a user 
locationmap.

>> For example, the "images/**.*" match currently uses
>> otherwise to match to an apparent backward compatibility set of
>> images.  It seems to make sense in these cases that locationmap
>> resolved images would resolve in a higher priority than the current
>> otherwise.  

Given that the test for the existence of a resource in the users 
locationmap may be expensive, i.e. it may request a remote resource, I 
think it should be the last test in the chain.

When we come to refactor the sitemaps either with a Forrest locationmap 
or for the 1.0 release we can reconsider this decision.

Ross

Re: matching order for image resources

[Nicola Ken Barozzi <ni...@apache.org>]

Tim Williams wrote:
> I'm struggling determining whether the matching order of images can be
> different from xml specifically with respect to locationmaps.  Should
> images *always* resolve through locationmaps as a last resort the same
> as xml?   

We should have two locationmaps: Forrest's and the user's.
The user's takes precedence on Forrest's.

> For example, the "images/**.*" match currently uses
> otherwise to match to an apparent backward compatibility set of
> images.  It seems to make sense in these cases that locationmap
> resolved images would resolve in a higher priority than the current
> otherwise.  

The user's locationmap should have a higher priority than Forrest's.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------