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 mappings. Meaning something like index.fv: <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0";> <forrest:view type="html" hooksXpath="/html/body"> <forrest:property name="branding-css-links-input"> <css url="common.css"/> </forrest:property> <forrest:hook name="horizon"> <forrest:contract name="genericMarkup"> <forrest:property name="genericMarkup"> <h1>Welcome, <a href="/start.html">start</a></h1> </forrest:property> </forrest:contract> </forrest:hook> </forrest:view> </forrest:views> 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 contract. Back in v3 I started to use the term internal structurer http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/template-sites/v3/src/documentation/content/xdocs/title-to-xhtml2.fv?rev=357566&view=log and placed them in the xdocs dir. http://svn.apache.org/viewcvs.cgi?rev=357581&view=rev 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} dir. 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 like structurer/ |-- internal |-- resource-types `-- url To solve FOR-621 with http://forrest.apache.org/docs_0_80/cap.html 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. wdyt? salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
