forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Further simplfying resources.xmap (Re: Q: Images-Cascade in Resources.xmap)
Date Thu, 20 Apr 2006 09:42:04 GMT
Thorsten Scherler wrote:
> El jue, 20-04-2006 a las 10:12 +0100, Ross Gardler escribió:
> 
>>Thorsten Scherler wrote:
>>
>>>El jue, 20-04-2006 a las 10:40 +0200, Ferdinand Soethe escribió:
>>>
>>>
>>>>Ross Gardler wrote:
>>>>
>>>>
>>>>
>>>>>Am I helping or confusing?
>>>>
>>>>Helping (me), thanks.
>>>>
>>>>
>>>>Still, I'm looking at this and wonder.
>>>>
>>>>It seems to me like these cascades create a behavior that is very hard to
>>>>predict by the user. And probably - unless you really study that
>>>>sitemap - for many developers as well.
>>>
>>>
>>>Yes, you are right the resource.xmap is *very* complex and *very* hard
>>>to understand.
>>>
>>>
>>>
>>>>Should we really have all this legacy support and usage pattern choices
>>>>implemented in this way?
>>>
>>>
>>>IMO no, that should go through the locationmap, however this is not that
>>>simple since we have a wide range of different matches that cannot
>>>directly be taken from the lm.
>>
>>I already refactored the resource.xmap to use the locationmap [1]. It 
>>has been massively simplified. From what I can see everything now goes 
>>through the the locationamp. What are the specific problems you still see?
> 
> 
> Stuff like 
> <map:resource name="pipe-text-resource">
>       <map:call resource="generate-transformed-resource">
>         <map:parameter name="path" value="{path}" />
>       </map:call>
>       <map:serialize type="text" mime-type="{mime-type}"/>
>     </map:resource>
> 
> Needs changes since you need to follow close to 5 different resource
> declarations to finally found the root of the processing.

Yeah, I remember having a nightmare trying to sort out that stuff when 
doing the locationmap refactoring. If it can now be simplified then that 
would be cool.


> Further 
> <map:match pattern="**.png">
>         <map:select type="exists">
>           <map:when test="{lm:project.images.{1}.svg}">
>             <map:call resource="pipe-aggregate-svg2png-resource">
>               <map:parameter name="path"
> value="{lm:project.images.{1}.svg}" />
>             </map:call>
>           </map:when>
>           <map:when test="{lm:project.images.{1}.aart}">
>             <map:generate type="asciiart-svg"
> src="{lm:project.images.{1}.aart}" />
>             <map:call resource="transform-project2text"/>
>             <map:serialize type="svg2png" />
>           </map:when>
>           <map:when test="{lm:project.images.{1}.png}">
>             <map:read src="{lm:project.images.{1}.png}"
> mime-type="image/png" />
>           </map:when>
>         </map:select>
>       </map:match>
> 
> We are doing here excessive use of the  <map:select type="exists"> which
> should be done in the lm IMO (but that is hard).

The LM maps one request to one resource. This snippet selects how to 
process the relevant resources once it has been discovered. I'm not sure 
what you envision being changed here, in my view resource resolving 
belongs in the LM and processing belongs in the sitemap. Isn't that what 
is happening in the above?

Ross

Ross


Mime
View raw message