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.
> >
> > 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 ?
> 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...
> 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.
Ok, now let's wait for other peoples opinion.
> 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 ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
