forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: SourceConf (was: Re: Removed xdoc copying (Re: cvs commit: ...))
Date Mon, 13 Oct 2003 13:27:05 GMT
Unico Hommes wrote:
> 
> Nicola Ken Barozzi wrote:
> 
...
>>If you want to start it, I'd be more than happy to assist 
>>you. In this 
>>way I can parallely do the other items that I have on my list :-)
> 
> Good thinking ;)
> 
>>This is the proposed xml format of the sourceconf:
>>
>><!-- the @default attribute says what default matcher is used to
>>       mount, and the @base prefixes all sources.
>>       Sources are resolves relative to the sourceconf location -->
>>
>><sourceconf xmlns="http://apache.org/forrest/sourceconf/1.0">
>>
>>  <mounts default-pattern="wildcard"
>>          default-select="resource-exists"
>>          base=".">
>>
>>    <!-- Asked for **.gif, return content/xdocs/{1}.gif -->
>>    <mount pattern="**.gif">
>>       <location src="content/xdocs/{1}.gif">
>>    </mount>
>>
>>    <!-- Asked for **.xml, return the first location that exists -->
>>    <mount pattern="**.xml">
>>      <location src="content/xdocs/{1}.ihtml">
>>      <location src="content/xdocs/{1}{2}.txt">
>>      <location src="{default}">
>>    </mount>
>>  </mounts>
>>
>></sourceconf >
>>
> 
> OK, just a few questions then on the element names. Why 'mount'? 
> Isn't'match' or 'map' more appropriate? 

I proposed it some days ago (look at the previous mails of this thread) 
but it got ignored. So I called it mount and somehow it started getting 
attention ;-)

Call it what you prefer, as long as it works it's ok with me.

> As for sourceconf element, 
> perhaps too specific, what about locationmap?

nice

> 
>>How can this be written as a first draft?
>>
>>You need to write an Inputmodule that gets as a config the 
>>location of 
>>the sourceconf.xml file.
>>
>>After loading the xml file, the SourceConfInputModule would then get 
>>mounts/@default and mount/@base and store the values.
>>
>>Then it cycles over the mount tags.
>>
>>For each mount tag, it gets the Matcher that corresponds to the @type 
>>hint from Avalon (or uses the default one), and stores the pattern.
>>Then for each of these, it stores all the locations.
>>
>>When a request comes, it would start cycleine over the list 
>>of mounts it 
>>has gotten, by asking the right Matcher if the current 
>>pattern matches.
>>
>>If yes, it asks for each location if it exists; I suggest 
>>that you use a 
>>selector for that, in this case the ResourceExistsSelector.
> 
> Ah, you're using Matchers and Selector for it, neat. But in order to
> use the complete range of possibilities shouldn't you use a more
> general syntax for it like in the sitemap:

I have used the smallest possible set of information for doing what we 
need now. KISS and extend later.

> <locationmap>
>   <match type="wildcard" pattern="**.gif">
>     <location src="content/{1}.gif" />
>   </match>
>   <match type="wildcard" pattern="**.xml">
>     <select type="exists">
>       <location src="content/xdocs/{../1}" />
>     </select>
>   </match>
> </locationmap>

This is very similar to my second draft. Again, use what you prefer, I'm 
ok with either as there is value in both approaches.

Having thought about it a bit, I tend to think that the latest format is 
easiest to use and read, which is not bad.

How about:

<locationmap xmlns="http://apache.org/forrest/locationmap /1.0">

   <matches default-pattern="wildcard"
            default-select="resource-exists"
            base=".">

     <!-- Asked for **.gif, return content/xdocs/{1}.gif -->
     <match pattern="**.gif" type="xxx" selector="xxx">
        <location src="content/xdocs/{1}.gif">
     </match >

     <!-- Asked for **.xml, return the first location that exists -->
     <match pattern="**.xml">
       <location src="content/xdocs/{1}.ihtml">
       <location src="content/xdocs/{1}{2}.txt">
       <location src="{default}">
     </match >
   </matches>

</locationmap>

>>The value the selector selects is the value to return. 
>>Remember that the 
>>values have to be resolved with the {x} parameters.
>>
>>To make this faster it can be done to cache the values it 
>>supplies for a 
>>defined time (an extra feature to be done later).
>>
>>What do you think?
> 
> I think I'd better start coding if I want to finish a first draft today!

:-D Good work then!

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



Mime
View raw message