El jue, 20-04-2006 a las 12:02 +0200, Cyriaque Dupoirieux escribió:
> 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 ?)
Good catch Cyriaque. You are totally right, we need to remove this
match.
> >
> >> 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,
No, don't be sorry. Thanks for asking for clarification, given me the
chance to explain better.
> >
> >> 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 :-) )
Yeah, I think I understand were you are hiding to and yes that is a very
good point. Thanks for explaining and I am in favor especially for
generic matches.
> > 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 ;-) .
jeje, please ask whenever you need clarifications.
> In my case, I need to override the tab-to-menu.xsl to have more
> information in my and it's a real mess...
Ok, I see. I think we need to refactor the dispatcher regarding this
data models. They should be based on structurer and contracts instead of
something like tab-to-menu.xsl. This way it is easy and fast to change
this. Maybe you and me (and others when interested) can tackle this on
some FF as team.
wdyt?
> >
> >> Maybe I should create an Issue for this ?
> >>
> >
> >
> > Yes, please.
> >
> > Thanks a lot Cyriaque for your efforts.
> >
> You are welcome,
>
:)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
