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)
