forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject [RT] structurer location and resource types (was Re: [announcement] DOCO prototype in forrest and lenya rep)
Date Wed, 22 Mar 2006 01:03:10 GMT
El mar, 21-03-2006 a las 10:53 +0100, Thorsten Scherler escribió:
> - make dispatcher aware of lenya resource types (I once added a resource
> type action to the dispatcher lm but actually we need a different one
> for lenya, since it keeps this information in a meta file). That means
> we need to extend the dispatcher with meta data lookups. That makes it
> possible to integrate different resource types (not only the xdocs based
> ones). Forrest will then be able to easiely bypass its internal format
> by looking up which structurer to use for the certain resource type.

The dispatcher is designed to be not document centric in its url

Meaning something like index.fv:
<forrest:views xmlns:forrest="">
  <forrest:view type="html" hooksXpath="/html/body">
    <forrest:property name="branding-css-links-input">
     <css url="common.css"/>
    <forrest:hook name="horizon">
     <forrest:contract name="genericMarkup">
      <forrest:property name="genericMarkup">
       <h1>Welcome, <a href="/start.html">start</a></h1>

does not need a index.xml, nor any other file (besides the css) but
returns perfect html markup. Till now we store it in the xdocs dir.

However lately I noted that keeping the structurer definitions within
the xdocs dir is starting to get real messy. 

Remember [branding-theme-profiler contract]
El jue, 16-03-2006 a las 11:57 +0100, Cyriaque Dupoirieux escribió:
> I think we have two improvements to do :
>     * first I tried to call custo.dispatcher.css in order to have a
>       unique customised css instead of getRequest.dispatcher.css
> (which
>       generates in my case several times the same file exactly)
>           o This does not work, the custo.dispatcher.css is empty (but
>             it's what I was expected ;-) )

The idea is to define one structurer for the "unique customised css".
Normally you would now create a path like {xdocs}/themes/css/profiler.fv
where you define the <forrest:view type="css"/> with the profiler

Back in v3 I started to use the term internal structurer
and placed them in the xdocs dir.
I needed to define 2 structurer and 2 different contracts 

* internal
1) xdocs/abstract-to-xhtml2.fv which is producing xhtml2 as new internal
format with
2) themes/common/xhtml2/abstract.ft 

* output
1) common.fv which is producing xhtml using
2) xhtml2-content-abstract.ft 

IMO this internal structurer definition do not belong into the {xdocs}

Resource types specific structurer have to be stored in a different
folder then the xdocs dir as well. 

IMO it makes sense to move them out of the xdocs dir and have something
|-- internal 
|-- resource-types
`-- url

To solve FOR-621 with is
not enough. 

"SourceTypeAction assigns a "type" (a string) to an XML file. This is
done based on information occuring in the header of the XML file, up to
the document (root) element."

This solution works perfectly for xml files but there are so many
non-xml files and formats that can mean a different source type and
needs a different structurer. 

We need a counterpart of the SourceTypeAction for non-xml formats and
keeping such information in meta data seems the most logical way. 



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

View raw message