cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Implementing <map:mount...> in Forrest Locationmap
Date Tue, 12 Jul 2005 00:33:23 GMT
-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Ross! Great to see Forrest is finally making use of the locationmap.
>I've been using it successfully myself for quite a while now.
>
>Ross Gardler wrote:
>> Quite some time ago Unico created a Locationmap module for Forrest.
>> This allows us to specify where the source file for a request is
>> located independently of the client request URL. this excellent code
>> has sat in our SVN for far too long, waiting for someone with a
>> strong enough itch to make real use of it. With the release of 0.7
>> and therefore the start of 0.8 development it has come out of hiding
>> and is now enabled in our core. It is a key part of integrating
>> repositories and CMSs such as Slide, Daisy and Lenya.
>> 
>> The Locationmap code [1] reuses code from Cocoon rather than starting
>> from scratch. 
>
>The part of Cocoon that is reused are Matchers and Selectors and some
>ideas in the treeprocessor package, but not the parsing and interpreting
>code of the treeprocessor itself which among other things concerns mounting.
>
>> We now need to enhance the code to allow the mounting
>> of sub-locationmaps in the same way that Cocoon can mount
>> sub-sitemaps. We are hoping that this can be done through a simple
>> reuse of Cocoon code. Unfortunately, nobody in Forrest knows the
>> insides of Cocoon well enough at this time so it would seem now is
>> time for some of us to learn...
>
>No problem, I don't think it will be too difficult. I'll try to answer
>any questions you may have as accurately as possible.
>
>> A locationmap consists of a number of matchers, for example:
>> 
>> <match pattern="remoteDemo/**.xml"> <location 
>> src="http://svn.apache.org/repos/asf/forrest/trunk/site-author/content/xdocs/{1}.xml
\
>> " /> </match>
>> 
>> For a complete locationmap file see 
>> http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/site-author/content/xdocs
\
>> /docs_0_80/locationmap.xml?rev=210059 
>> 
>> 
>> The map is built by the build(...) method in 
>> org.apache.forrest.locationmap.lm.LocationMap (see 
>> http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/java/org/apache/forrest/locatio
\
>> nmap/lm/LocationMap.java?view=markup )
>> 
>> As can be seen in this code Unico reused much of the sitemap code
>> from Cocoon. My question is, can we also leverage the <map:mount...>
>> code? Any pointers as to how to do this would be greatly appreciated.
>
>I mostly only reused the XML syntax not the actual tree building code
>from the treeprocessor package. For instance treeprocessor distinguishes
>between NodeBuilders and Nodes itself, I did not deem that neccessary
>for the locationmap because it is much simpler and limited in scope. But
>the mount mechanism should be similar.

I, too, would first like to say thanks for the locationmaps....

I'm obviously not as familiar with Cocoon internals as I should be,
but I wonder since much of Forrest is about location resolution is
there a reason we wouldn't want to fully implement a locationmap
language?  In other words, it seems like the original idea [and
perhaps the current idea] is simple and limited, but why not poise lm
for growth.

Specifically, why not extend our own DefaultTreeBuilder with
LocationmapLanguage, create a locationmap-language.xml and have a
foundation that can grow in the exact same way the sitemap language
can grow? Could the TreeProcessor not handle the two "languages"
together?  Is it overkill?

>Here's a rough list of what it involves to implement:
>
>- - Create a new class MountNode that represents a <map:mount> statement.
>- - Add code that creates and builds new MountNode objects whenever
><map:mount> is encountered (duh)
>- - Implement MountNode:locate. You'll need the same code that is in
>LocationMapModule:getLocationMap() Probably factor out into an
>accessable static method for reuse. Then call LocationMap:locate with
>the rest of the hint.
>- - There may be a need to pass the parent LocationMap's InvokeContext
>along to the child LocationMap but probably not. You'd need to change
>LocationMap:locate method signature for that and then pass the parent
>InvokeContext when constructing the child InvokeContext (I think).
>
>Hope that helps :)

It certainly does...
--tim

Mime
View raw message