> 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. > > > > > > 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... > Eagerly waiting...
> > 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. Hm, also I don't like it, this might be a solution with minimum problems. > - 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'm not sure if the Request is used more than the SourceResolver. But let's not argue about that. I don't like looking up Request and Response objects from the objectModel, either. Yesterday I was thinking if I should make a proposal to change the type of the objectmodel from a Map to a custom class. The interface looked similar to your ObjectModelHelper with addition get() and put() methods to hold any objects in it - like the map currently does. I discarded this, as it might be a too dramatical interface change. > > Ok, now let's wait for other peoples opinion. > Yupp! > > 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 ? No I don't mind and I will from time to time send a RT (as I did over the last weeks). But I will not do this before we have the final release. Sorry, but we still haven't had any release, so we should more focus in this then on new great ideas. (Of course, these ideas are always welcome and appreciated). Carsten > -- > Sylvain Wallez > Anyware Technologies - http://www.anyware-tech.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
