cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: The Problems with Sitemap Factories
Date Wed, 17 Oct 2001 16:01:58 GMT
> 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.
>
> 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.
We have to change the two Interfaces (Matcher and Selector) anyway,
so it shouldn't hurt to add the SourceResolver into one signature.

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.

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

> > 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
>


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


Mime
View raw message