Return-Path: 
 <cocoon-dev-return-17822-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 31261 invoked by uid 500); 17 Oct 2001 11:54:56 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 31230 invoked from network); 17 Oct 2001 11:54:55 -0000
Message-ID: <3BCD71AB.B03C813B@anyware-tech.com>
Date: Wed, 17 Oct 2001 13:55:23 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
X-Mailer: Mozilla 4.7 [fr] (WinNT; I)
X-Accept-Language: fr,en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: The Problems with Sitemap Factories
References: <GMEBIBHGAOFGJCDPJANDGEBDCPAA.cziegeler@sundn.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



Carsten Ziegeler a �crit :
> 
<snip/>

> > There's another point on which we still didn't came to a clear decision
> > : what about making the SourceResolver available to matchers and
> > selectors ? Can't it be simply added to the ObjectModel ?
> >
> To be compatible we shoud pass the SourceResolver as a separate object
> in the method as the other interfaces do the same.

Mmmh... and what about the other way ? If the SourceResolver becomes
generally available, let's add it to the object model so that we don't
have to pass it as a parameter everywhere.

If we don't want to change now APIs that have this parameter, we can
"deprecate" its use (in the doc, because we cannot put @deprecated on a
parameter). These methods will have two ways to access the
SourceResolver, but this shouldn't hurt.

This will avoid API changes now (no more, no less parameters) and
prepare for a future release where these parameters would be removed.
Also, the interpreted sitemap to come may allow to handle more easily
different interfaces that implement a single sitemap element than today
(I'm starting heavy thinking about that ;)

Thoughts ?

> Carsten
> 
> > Sylvain.
> > --
> > Sylvain Wallez
> > Anyware Technologies - http://www.anyware-tech.com
> >
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org