le 20/04/2006 11:18 Thorsten Scherler a écrit :
El mar, 18-04-2006 a las 10:55 +0200, Cyriaque Dupoirieux escribió:
Hi,
I think...
[snip]
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).
Ok, but do we still need to search in a skin directory, it's a little
strange using the dispatcher (or maybe it's just backward 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.
Ok, now it's clear, sorry,
Second, we need to verify the fall backs :
------------------------------------------
[snip]
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.
Yes, but with the previous solution, you don't need to override the
lm-matches, you simply add a custom xsl file and import the standard !
(think about it :-) )
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.**">.
I don't know, at the moment I need to continue to investigate and
understand the lm ;-) .
In my case, I need to override the tab-to-menu.xsl to have more
information in my and it's a real mess...
Maybe I should create an Issue for this ?
Yes, please.
Thanks a lot Cyriaque for your efforts.
You are welcome,
Cyriaque,
salu2
