Tim Williams wrote:
On 7/8/05, Ross Gardler <[EMAIL PROTECTED]> wrote:
Tim Williams wrote:
I'd prefer project-level locationmaps to be overrides or extensions
rather than replacements for the app-level locationmap.
That's the intention, though not well described in the commit message.
The implementation I put in place is to get things working quickly since
we broke head. I intend to modify the LocationMapModule class to mount
an empty locationmap if it cannot find the project one (i.e. do what the
current workaround does). In the meantime we can start building the
forrest locationmap.
Unfortunately, locationmaps don't have
the same concept of "mounting" so that we could simply mount
project-level lm's ahead of the app-level one.
Yes they do - at least in theory, I've not tested it yet. If I
understand it right pretty much any of the map: elements can be used (or
easily be made to work).
It looks to me like it's an implementation that mimics the sitemap
syntax but doesn't necessarily make use of it's full power (e.g.
TreeProcessor,etc.).
I've looked into the source in more detail, and you are right.
I therefore propose we build the locationmap using XSL. I want plugins
to be able to provide their own locationmaps as well as projects, but we
should start with the simple case of project sitemaps. So we would have
something like:
<map:match pattern="locationmap.xml">
<map:aggregate element="locationmaps">
<map:part src="{forrest:locationmap}"/>
<map:part src="{project:content}/locationmap.xml"/>
</map:aggregate>
<map:transform
src="{forrest:stylesheets}/locationmapAggregate2locationmap.xsl"/>
<map:serialise type="xml"/>
</map:pattern>
NOTE: we would have to have a test to ensure that the project
locationmap existing.
In the XSL we would merge all the components and give priority to
locators as follows:
project -> plugins -> forrest
At a later date we may decide to put this behaviour in the java code.
But for a "get it working" solution I think this will work.
Comments?
Ross
