forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Re: Understanding the dispatcher
Date Fri, 24 Nov 2006 09:23:22 GMT
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)


Mime
View raw message