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