Dispatcher - structuring the content model (was: Mapping URLs to documents)

[Thorsten Scherler <th...@apache.org>]

Hi all,

thx Andreas for mentioning 
http://wiki.apache.org/lenya/ProposalContentModel
again and starting the URL discussion. Really nice presented
information.

The latest discussion about URL mapping [1] and the above mentioned wiki
page sounding like the reason I started my work on the dispatcher (in
forrest - first implementation in the next release). It was called
forrest:views in the beginning to express its main purpose but views is
an often used term and in the end caused confusions. 

A view is for me an aggregation of different data sources transformed
for a specific format. The URL
http://lenya.apache.org/community/index.html is defined by the html view
of the document http://lenya.apache.org/community/index. Andreas called
it canonical URL which is the path *without* file extension and seems to
share this definition of "view".

I have sometimes problems with the usage of "document". In a html view a
document is the main content. *Not* the navigation, menu, ... that is
extra content. It can contain *links* to other assets but normally not
keep them. 

...but IMO a URL does not have to be connected to *just* one "document"
or to a document at all. 

El vie, 06-01-2006 a las 14:24 +0100, Andreas Hartmann escribió:
> Supporting the other case, multiple URL suffixes for a document, is
> certainly
> necessary. But I'd separate this information from the document itself.
> IMO the URL suffix should be used to request a certain view of a
> document:
> 
> /foo              -> HTML view
> /foo.html         -> HTML view
> /foo.pdf          -> PDF view
> /foo.print.html   -> print HTML view (if CSS is not appropriate or
> whatever)
> 
> The canonical URL of a document whould be assembled from the canonical
> base URL (/foo) and the extension denoting the view.

In the default publication the html view is done in the page2xhtml.xsl.
Here we are arranging the different contracts (like breadcrumb, tabs,
menu, ...) which are coming from an earlier aggregation as input. 

The main problem with this approach is that it is expecting a given data
model (aggregation) which is not easily extensible. Further more some
views are not using all the data model given by the aggregation (e.g.
*.print.html will probably only render the main document and not any
menus). 

IMO each URL space should be able for deciding which business services
(such as documents, assets, navigation, ...) to use and how to render
the resulting business data. 

This leads to a different URL handling focus - away from document
centric. A document can be (but do not have to be) behind a certain URL.
In the forrest dispatcher that is controlled by the structurer.

http://forrest.apache.org/docs_0_80/howto/howto-structurer-dsl.html

"We developed the structurer to let the user decide where to place
elements in e.g. html pages. We started this work with the skinconf.xml
where you could configure certain elements and their positions. These
elements were known under certain names. It was up to the skin designer
to support this configuration and the elements

...

The structurer allows us to define the order in which forrest:contracts
appear, and also to group them using forrest:hooks. 

forrest:hooks are containers that are only used for layout reasons. They
do not add any content nor functionality to the output. They add only
layout information to the output. Actually e.g. a <forrest:hook
name="layoutId"/> will be transformed to <div id="layoutId"/> 

forrest:contracts are functionality or extra content that a theme can
use to display the request. Sometimes a contract delivers
format-specific markup, other times it delivers a format-independent
string. We decide different kind of contracts, static one (like
described in the contract howto), semi static (which offer configuration
parameter in the structurer) and dynamic contracts (which offer
semi-static configuration and/or requesting the content)."

http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/main/template-sites/v3/src/documentation/resources/themes/common/html/content-minitoc.ft

This is the contract to generate a table of content of an xdoc in
forrest. It should demonstrate the idea of contracts in general. They
are standalone, self explaining, configurable pieces of xsl templates
created out of pure maintaining reasons. 

http://forrest.apache.org/docs_0_80/howto/howto-structurer-contracts.html#enhanceMaintenance

This contracts provide
1) description -  what does the contract do? What do the properties
mean? What else does the user have to know?
2) usage - how can I use the contract in the structurer?
3) implementation - till now the dispatcher only supports xsl as
inputFormat but that should be extensible in the future.

If you look at the link again, you will find in the usage tag
dataURI="cocoon://#{$getRequest}.toc.xml". This attribute, defined in a
structurer, makes the dispatcher contact
cocoon://#{$getRequest}.toc.xml" for the input data for this contract.
If you need to contact more then one business service in for a contract
one can jx:import as many as one want since the structurer is a jx
template. 

Now let us say $getRequest="index", then we are requesting the uri
cocoon://index.toc.xml. This could be the result from the toc.xml view
on the document (id="index"). The site structure finally defines which
"document" (main content) with id="index" is linked.  With the
dispatcher you can even create a view on a URL where no "document" (main
content) exits e.g. just static output.

The URL mapping is defined by the theme fallback mechanism of the
dispatcher. You can define for each URL a specific view (structurer) or
you can define a directory based one or you can use the theme default
structurer or the forrest core structurer. 

...and all this for different formats.

salu2

[1] http://marc.theaimsgroup.com/?t=113655405500001&r=1&w=2
-- 
thorsten

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