From dev-return-23653-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org Thu Apr 20 10:01:33 2006 Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 77894 invoked from network); 20 Apr 2006 10:01:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Apr 2006 10:01:19 -0000 Received: (qmail 11739 invoked by uid 500); 20 Apr 2006 10:00:50 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 11569 invoked by uid 500); 20 Apr 2006 10:00:50 -0000 Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@forrest.apache.org List-Id: Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 11547 invoked by uid 99); 20 Apr 2006 10:00:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Apr 2006 03:00:50 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [81.80.68.197] (HELO daikiri.pcotech.fr) (81.80.68.197) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Apr 2006 03:00:49 -0700 Received: from macadam.pcotech.fr (macadam.pcotech.fr [192.168.108.3]) by daikiri.pcotech.fr (8.11.6/Aquarel-5.5.8) with SMTP id k3KA0Q729294 for ; Thu, 20 Apr 2006 12:00:26 +0200 (MET DST) X-Url: http://www.pcotech.fr Received: from b52.pcotech.fr ([192.168.101.124]) by macadam.pcotech.fr (SMSSMTP 4.1.0.19) with SMTP id M2006042012002520142 for ; Thu, 20 Apr 2006 12:00:25 +0200 Received: from [192.168.106.27] (dhcp-tlse-27.pcotech.fr [192.168.106.27]) by b52.pcotech.fr (8.12.8/8.12.8) with ESMTP id k3KA0PFf025037 for ; Thu, 20 Apr 2006 12:00:25 +0200 Message-ID: <44475C45.30301@pcotech.fr> Date: Thu, 20 Apr 2006 12:02:45 +0200 From: Cyriaque Dupoirieux User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dev@forrest.apache.org Subject: Re: [Dispatcher location map] References: <4444A995.2060800@pcotech.fr> <1145524727.7933.47.camel@localhost.localdomain> In-Reply-To: <1145524727.7933.47.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 : >> >> >> >> >> >> >> >> >> 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 : >> >> >> > > 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. 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 >