Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 50501 invoked from network); 21 Jun 2005 08:09:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Jun 2005 08:09:44 -0000 Received: (qmail 88784 invoked by uid 500); 21 Jun 2005 08:09:43 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 88611 invoked by uid 500); 21 Jun 2005 08:09:40 -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 88597 invoked by uid 99); 21 Jun 2005 08:09:40 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jun 2005 01:09:40 -0700 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [81.169.145.166] (HELO natnoddy.rzone.de) (81.169.145.166) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jun 2005 01:09:42 -0700 Received: from noq.dserv.dserv.w2k (pD95EA9CB.dip.t-dialin.net [217.94.169.203]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j5L89bvc009534 for ; Tue, 21 Jun 2005 10:09:37 +0200 (MEST) Subject: Re: Locationmap and sitemap.selector.exists From: Thorsten Scherler To: dev@forrest.apache.org In-Reply-To: References: <1119257585.7349.17.camel@localhost.localdomain> <42B746C3.6030309@apache.org> Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 21 Jun 2005 10:09:36 +0200 Message-Id: <1119341376.5239.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 8bit X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Tue, 2005-06-21 at 08:20 +0200, Nicola Ken Barozzi wrote: > Ross Gardler wrote: > ... > > Another use case for what you suggest is the resources.xmap file. > > Imagine how much easier to follow it would be if we didn't have so may > > alternative locations for the image files. Nicola Ken hinted that this > > would be the case when I recently said I don't want to think that far > > forward yet. I wonder if this is what he meant? > > Yes. As Thorsten has seen, Having the information early can make the > sitemaps much cleaner. > > But instead of "exists", we should use another selector. Let me explain. > > Cocoon has the notion of "Source", and there is also a > "TraversableSource". This means that I can go further than asking a > source if a file exists, I can ask to give me all the files that have a > given name except the extension. This would make it all much faster and > cleaner. > > For example, if the TraversableSource is the file system, my action > would ask all the filenames in a certain directory, and with a for loop > get all the ones with the same name in the requested URI, sorting the > extensions as I tell him to. In this way, the result of the processing > is *one* *source* *file*! > That is why you always have been talking about: about.xml about.meta.xml ... right? The question that raises is whether that is working as well for subdirectories. Let me explain: I have a contract not only in {project:resources}/templates/ but in e.g. {project:resources}/templates/xhtml/{1}.ft {project:resources}/templates/fo/{1}.ft Now would the TraversableSource respond me when looking for {1} the fo/ and the xhtml/ dir location or only in one dir (without subdir)? What do you exactly mean with *one* *source* *file*? Do you mean eg. index.xml and index.fv can be treated as *one* file because their have only the extension different? > Imagine, from the very beginning we know what the source is without > lengthy and tedious requests, and we can start processing by knowing > what the source is from the beginning. > Separation of Concerns: location resolving and processing fully > separate, also inside Cocoon. > Requesting index.html would give me index.xml and index.fv through the TraversableSource (in locationmap). This resolving would then be used later on in the processing which will not care about resolving but concentrate on processing. That makes the sitemap really clean and readable. :) ���wow!!! Now I am starting to understand better what you wrote in old mails. ;-) Good on ya, mate. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)