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 Fri, 21 Apr 2006 18:57:39 GMT
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)


Mime
View raw message