cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Implementing <map:mount...> in Forrest Locationmap
Date Mon, 11 Jul 2005 11:39:50 GMT
On Mon, 2005-07-11 at 12:57 +0200, Unico Hommes wrote:
> 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.

First of all great work Unico (OT BTW in spanish your name means "the
only one"). :)

Talking about selectors in the lm. I gave it a shoot last month with the
select type="exist", but I was stumbling over the map:when/otherwise
syntax that seems not be implemented in the lm.

How do we (I am as well from forrest) have to extend that part? Maybe
you would like to join force again because now that we understood the
power of your work, we would like to further enhance it. You are the
creator and I guess you know how to get the most out of it. ;-)

Thanks for helping us out.


> > 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="{1}.xml"
> >  /> </match>
> > 
> > For a complete locationmap file see 
> >*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 
> >
> >  )
> > 
> > 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.
> 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 :)
> - --
> Unico
> Version: GnuPG v1.4.1 (Darwin)
> iD8DBQFC0lCCcuec8tVNKAwRAoFbAJ9PnvHJohngvNisS8F8eRvD79sWsACdFlS0
> /HhYc41pEXYHYodQbRBeElM=
> =lLjR

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message