forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject SourceConf (was: Re: Removed xdoc copying (Re: cvs commit: ...))
Date Mon, 13 Oct 2003 11:50:57 GMT
Unico Hommes wrote:
> Hi Nicola,
> Last friday a collegue asked me for almost exactly this! We need it
> for more powerful semantic linking than the current modules support.
> So perhaps we can work together in creating this thing? 


> Do you already have code somewhere? 


> I'd like to take a look at it. One thing
> I'd like to add is a way to configure the module as to whether to do
> resource exists checking.

What I have been doing these days was to think about the inplications,
the xml format, and document myself on how to use Avalon components, as
it's quite some time since I worked /on/ cocoon rether than /with/.

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 :-)

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="">

  <mounts default-pattern="wildcard"

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

    <!-- 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}">

</sourceconf >

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.

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?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message