forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [Dispatcher location map]
Date Thu, 20 Apr 2006 09:18:47 GMT
El mar, 18-04-2006 a las 10:55 +0200, Cyriaque Dupoirieux escribió:
> Hi,
> 
>     I think that the location map of the dispatcher needs to be cleaned 
> and self documented - generally, I cannot retrieve where variables - 
> such as {project.structurer} point.

You are right we need to slim down the lm. {project.structurer} was
thought to be a custom structurer defined in forrest.properties. In the
upcoming month I can provide an example for this. 

http://issues.apache.org/jira/browse/FOR-799 this forces us to use a
forrest independent way of defining dispatcher properties.

>     I try to understand the location map - and it's not quite easy :-)  
> - and I think fallbacks mecanism should be homogenised.
> 

+1

> First, we need to be homogeneous :
> ----------------------------------------------------
> 
>     For instance in some patterns - such as 
> pattern="dataModel-html-**.xsl", the location map looks into :
> 
>     * src="{project:structurer}/resources/stylesheets/html/{1}.xsl"
>     * src="{project:skins-dir}{project:theme}/xslt/html/{1}.xsl"
>     * and src="{defaults:structurer}/resources/stylesheets/html/{1}.xsl"
> 
>     And in other patterns - such as pattern="contract-strip-xsl.xsl", 
> the location map looks into :
> 
>     * src="{project:structurer}/resources/stylesheets/contract-strip-xsl.xsl"
>     * and
>       src="{defaults:structurer}/resources/stylesheets/contract-strip-xsl.xsl"
> 
> And we don't know why it does not search in skin-dir ?

I reckon we just forgot the match. However the dataModel stuff should be
done with internal structurer and contracts and not anymore with e.g.
document-to-xhtml.xsl. I think we should take this chance and base the
dispatcher on xhtml2 and not on xdocs anymore (the xdocs plugin will
grant downwards compatibility).

> 
>     Another example is the use of different pathes which seem to be the 
> same :
> 
>     * {project:structurer}/resources
>     * and {project:resources}

No, project:structurer/resources is != project:resources. The idea of
project:structurer is to have a custom implementation of the
internal.dispatcher plugin and not using the forrest one. The project
resources however are not having this focus. 

> Second, we need to verify the fall backs :
> ------------------------------------------
> 
>     In other patterns, it seems the location map looks twice in the same 
> location :
>     <match pattern="dataModel-xml-document-to-**.xsl">
>       <select type="exists">
> *            <location 
> src="{project:structurer}/resources/stylesheets/xml/document-to-{1}.xsl" />*
>             <location 
> src="{project:skins-dir}{project:theme}/xslt/xml/document-to-{1}.xsl" />
> *            <location 
> src="{project:structurer}/resources/stylesheets/xml/document-to-{1}.xsl" />*
>             <location 
> src="{defaults:structurer}/resources/stylesheets/xml/document-to-{1}.xsl" />
>       </select>
>     </match>

Seems to be a copy'n paste error, but this is the part we need to
refactor (see above).

> At last, we may add entry points to have the possibility to override 
> everything :
> ------------------------------------------------------------------------------
>     For instance to systematically have an entry point pattern to 
> override a stylesheet and a standard pattern :
> 
>     <match pattern="dataModel-xml-document-to-**.xsl">
>       <select type="exists">
>             <location 
> src="{project:structurer}/resources/stylesheets/xml/document-to-{1}.xsl" />
>             <location 
> src="{project:skins-dir}{project:theme}/xslt/xml/document-to-{1}.xsl" />
> *            <location src="{lm:std-dataModel-xml-document-to-{1}.xsl" />*
>       </select>
>     </match>
>     <match pattern="std-dataModel-xml-document-to-**.xsl">
>       <select type="exists">
>             <location 
> src="{defaults:structurer}/resources/stylesheets/xml/document-to-{1}.xsl" />
>       </select>
>     </match>
> 
> With these two patterns, the customiser can create his own 
> document-to-html.xsl in his project directory and import the standard in 
> this stylesheet :
>       <!-- Standard Import... -->
>       <xsl:import href="lm://std-dataModel-xml-document-to-html.xsl"/>

I am not sure, since the nature of the lm is that user can override core
lm-matches in their own locationmap. If we start to add different
alternatives then we pretty soon end up in a bigger confusion then we
already have.

Maybe we should skim all matches to a bare 2 location pattern and only
provide a full blown away fallback mechanism for stuff like e.g.  <match
pattern="resolve.structurer.**">.


> Maybe I should create an Issue for this ?


Yes, please. 

Thanks a lot Cyriaque for your efforts.

salu2
-- 
thorsten

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


Mime
View raw message