Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BCEE1E6.262C10A3@apache.org>
Date: Thu, 18 Oct 2001 10:06:30 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: The Problems with Sitemap Factories
References: <GMEBIBHGAOFGJCDPJANDIECCCPAA.cziegeler@sundn.de>
 <3BCE9F54.3DA33FE4@anyware-tech.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Sylvain Wallez wrote:
> 
> Carsten Ziegeler a �crit :
> >
> > > Sylvain Wallez wrote:
> > >
> > > 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.

If you @deprecate the whole method, replacing it with the correct version,
you can modify the base Abstract class so that the deprecated method calls
the new method (or vice versa).  That way, no matter which one the user
overrode in the end, they still get the correct (or expected) results.

> > > 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 ?
> > >
> > I really would like to hear other opinions on this than our two's.
> 
> Yep : HEY, TEAM, WHAT DO YOU THINK ?

If you mark it as deprecated sooner than later, then you give folks a heads
up that it is going to change.

> > We have to change the two Interfaces (Matcher and Selector) anyway,
> > so it shouldn't hurt to add the SourceResolver into one signature.
> 
> Mmh... not so sure now. After more thinking, it appears to me we should
> keep separate interfaces for Matcher and PreparedMatcher. This would
> reduce sitemap setup time for Matchers that don't require it and allow
> to keep the pattern parameter as a String, as you seem to prefer it, for
> non-prepared matchers. More about this soon...

The whole filter proposal I had a while back would supercede the matcher/selector
interface, and possibly be a base class for them.  The whole thing is that
they affect the pipeline differently.  I will have to put together a RT that
redescribes everything.

> > But I think you're right: the objectModel seems exactly the right
> > place to hold such objects, rather than adding separate parameters
> > for each.
> >
> > So the solution should be adding it to the objectModel and removing
> > the parameter from the methods. This has three disadvantages: first -
> > of course - incompatible interface changes and second some slight
> > performance loss as nearly each component first queries the objectModel
> > to get the SourceResolver before using it. The third one: the code
> > becomes less readable as one more object is hidden in a Map.
> 
> Several points here :
> - incompatible interface changes : interfaces that have today both
> object model and SourceResolver can live unchanged with an enhanced
> object model. This small inconsistency would be the price for
> compatibility.
> - performance loss : right, but consider the request : it's much more
> used than the source resolver and is only accessible from the object
> model
> - less readable code : agree. Take a look a the new ObjectModelHelper in
> the 2.1 cvs : I often use this pattern to provide typed access to
> well-known entries in a Map or request and session attributes.

I like the ObjectModelHelper idea, and now wonder why it wasn't introduced
sooner.

The idea behind the object model is a method of providing a unique
context per request.  This is distinct fromt the Context object which is
used to provide a unique static (as in unchanging) context.

To this end, I would rather extend the ObjectModelHelper idea to the point
where the ObjectModel is a first class citizen.  I originally thought that
the Environment class was going to take on this role (as of last year).
It turns out that there are other purposes for the Environment.  It makes
sense that the ObjectModel should have accessors for specific environment
components (Request, Response, Session, etc.).  Since this does not affect
Sitemap Factories (something I dislike anyway) I will post this in another
RT regarding the environment model--which would require some deprecation.


> > Looking at all the RTs which passed in over the last weeks
> > and looking through my own wish-list for the Cocoon development,
> > I fear that there might be incompatible interface changes after a
> > final release, anyway. Having this in mind, I would prefer only adding
> > the SourceResolver to the signature of Matcher and Selector
> > and leaving everything else as it is.
> >
> > Carsten
> 
> Would you mind telling us about your wish list ?

If the Matcher and Selector receive the SourceResolver through the ObjectMap,
then there would be no need.  In fact the new ObjectMap first class citizen
would be able to extend Map so that the signatures of most methods do not need
to be changed yet.

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