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)
