On Fri, 2006-11-24 at 01:32 +0100, C. Grobmeier wrote: > Hi all, > > i have read all docs i could found about the dispatcher. Please correct > me if i didn't understand something correctly. > > The Dispatcher is made of three main components, the structurer, the > hooks and the contracts.
The structurer is the request specific presentational view on data. This data can come from different input sources. To be able to create a structure for designer we define hooks. Contracts are transformed content/functionality coming from any given data source (defined in the @dataUri). The dispatcher in a dev point of view actually consist only of two components. The dispatcher config (aka structurer) and the transformation/dispatching in internal processing of the definition. That is as well why we have two core dispatcher plugins (dispatcher and themes). > > Contracts are definitions of functionality. They implement no design > stuff but the can have params etc. Functionality and extra content. Yes, structural markup should be omitted whenever possible to higher the re-usability factor. > > Hooks are nothing else but tags, in which i can write my contracts to > give em CSS. Example: > > <forrest:hook name="header"> > <forrest:contract name="my-contract" /> > </forrest:hook> > > Would put the result of my-contract in a div with the class header. > Yes, totally right. > The structurer is used to put the things in place. Means, i want the > menu right, ok no, problem, i put the menu-contract in the hook with the > css things to put everything at the right side. Yes, totally right. > I can't use a contract in a content-file like index.xml- why? Doesn't it > make sense for some content to have a contract like "show-img" or > something like that? > This is a dev topic and should be discussed over in the dev list. Short answer I am still thinking about this since the beginning. On the one hand this would make it easier to aggregate content prior the presentational stage, but on the other hand it can mix concerns. That said I actually use a workaround to simulate what you describe. Since the extension .xml is reserved in internal forrest processing we are using .internal* as extension. Now index.internal you can define in the structurer. Let us say you have a side that would need to aggregate always *.xml + *.extra-content.xml as incoming data for the contract content-main then you can define in the main structurer: <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"; xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";> <!-- The following variables are used to contact data models and/or contracts. --> <jx:set var="getRequest" value="#{$cocoon/parameters/getRequest}"/> <jx:set var="getRequestExtension" value="#{$cocoon/parameters/getRequestExtension}"/> <!-- internal View of the request e.g. index.internal --> <forrest:view type="internal" hooksXpath="/"> <forrest:contract name="content-main" dataURI="cocoon://#{$getRequest}.body.xml"/> <forrest:contract name="extra-content" dataURI="YOUR_EXTRA_DATA_FACTORY_URI"/> </forrest:view> <!-- HTML View of the request (e.g. index.html)--> <forrest:view type="html" hooksXpath="/html/body"> <forrest:contract name="content-main" dataURI="cocoon://#{$getRequest}.internal"> <forrest:property name="content-main-conf"> <headings type="underlined"/> </forrest:property> </forrest:contract> </forrest:view> </forrest:views> To make the above work you need to have in your theme dir the internal/ dir and the contracts in there that you use in the internal part of the structurer. > > Is there somewhere a document where i can look what tags i can use in > the structurer? f.e. i mean <forrest:contract> and so on. Yes, we recommend to install firefox and the forrestbar, there a lot of helpful links as well for the dispatcher. To answer your question, you need to have a running dispatcher site in dynamic mode and then request http://localhost:8888/ls.contracts.html this returns all contracts that the core themes provide with description and usage example. http://localhost:8888/ls.contracts.project.html is showing the ones you have in your project. > > I will now read the locationmap stuff, cause i am unsure how to handle: > dataURI="cocoon://#{$getRequest}.toc.xml" > or stuff like "*.navigation.xml". So more i read about dispatcher so > more i understand, but sometimes there are these statement and i don't > know how to use em. Are there other docs which can help me to understand > what happens with this? The source code. Serious I added a lot of comments into the code which are related with dispatcher internals. In your special case have a look into dataModel.xmap from the dispatcher plugin. > > Sorry for this questions, but dispatcher is a too great enhancement not > to ask about it. :-) jeje, thanks for the compliment and no worries, keep on asking and if you find you can enhance the documentation then feel free to send patches. salu2 > > Thanks, > Chris -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
