2009/8/19 David Crossley <cross...@apache.org>:
> Sjur Moshagen wrote:
>> Hello all,
>>
>> For a long time our project group has been using an ical output
>> project module that I'm now converting to a real plugin, which I
>> intend to add to the whiteboard. For historical reasons, the url
>> pattern matched against presupposes a certain file naming scheme, as
>> follows:
>>
>> <!-- Will match weekly meeting files {2}, and extract the tasks for
>> the
>> person in {3}, returning the task list as an iCal TODO list -->
>> <map:match pattern="**/Tasks_*_*.ics">
>> <map:generate src="cocoon://{1}/Meeting_{2}.xml" />
>> <map:transform src="{lm:ical.transform.document.ics}">
>> <map:parameter name="date" value="{2}" />
>> <map:parameter name="person" value="{3}" />
>> </map:transform>
>> <map:serialize type="ical" />
>> </map:match>
>>
>> That is, the meeting date is encoded in the filename, and the person
>> for which the ical file should be created is encoded in the URL in
>> addition to the date. Also, the filename is fixed to the pattern
>> "Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,
>> or should I change to a more general pattern? One reasoning is that it
>> doesn't make sense to create an ical file for a non-meeting document,
>> and this dependency is expressed in the URL and filename patterns. But
>> then again, the whole plugin depends on certain conventions in the
>> source document, so you can anyway add non-working links (ie link to
>> meeting documents that do not follow these conventions).
>>
>> Comments on the URL or filename patterns? Other comments?
>
> This is exiting. That seems like a fine approach to me.
I agree that it's great to see some new work here. I don't quite agree
that the URL patterns is a "fine approach" though. But don't worry,
it's a small change I am going to propose and it is backward
compatible with your current scheme.
Basically, some time ago we decided that fixed url patterns were a bad
idea since it creates potential clashes in peoples applications. We
therefore implemented the new (although not officially released) XML
properties system to allow the sitemap to be easily configured without
having to edit the plugin files (actually that was a side effect, but
that's not relevant right now).
You can see an example of this approach in use in the Daisy input
plugin (whiteboard):
input.xmap:
<map:match
pattern="{properties:daisy.pathPrefix}*{properties:daisy.fileExt}.xml">
<map:call resource="daisy-to-document">
<map:parameter name="docID" value="{1}"/>
<map:parameter name="path" value="{0}"/>
</map:call>
</map:match>
forrest.properties.xml:
<property name="daisy.pathPrefix" value=""/>
...
<property name="daisy.fileExt" value=".daisy"/>
Now the project can override these properties in its local
forrest.properties.xml if it needs to do so, or it can leave them at
their defaults for the same behaviour as your existing sitemap.
Ross
