2010/2/4 Kristian Marinkovic <kristian.marinko...@porsche.co.at> > as with the activation context i think it would be very > error prone (from my exprience). what if you really > swap the parameter positions, consider more than > two parameters. i think the chance to create bugs that > cannot be detected by unit tests increases. except you > have very good integration tests. > > but... if we had additional positional annotations > or an own marker annotation to distinguish them.... > > i think it would we a good idea as you could spare > some indirections >
Nice idea ! > > g, > kris > > > > > cordenier christophe <christophe.corden...@gmail.com> > 04.02.2010 15:16 > Bitte antworten an > "Tapestry users" <users@tapestry.apache.org> > > > An > Tapestry users <users@tapestry.apache.org> > Kopie > > Thema > Re: Multiple configuration items per service > > > > > > > 2010/2/4 Kristian Marinkovic <kristian.marinko...@porsche.co.at> > > > hi, > > > > i guess it is so because it is difficult to distinguish the > > contributions if they are of the same type: > > > > Filter(Collection<String> whitelist, Collection<String> blacklist>) > > > > contribute(Configuration<String> blacklist, Configuration<String> > > whitelist) > > > > Also i think ordering should be sufficiant, this is what happen with > activation context methods. Don't you think ? > > > > > > i solve these type of problems by creating two seperate services either > > with an own interface (BlackListSource, WhiteListSource) or by binding > the > > same class with two different service identifiers... just another > > indirection :) > > > > g, > > kris > > > > > > > > > > > > cordenier christophe <christophe.corden...@gmail.com> > > 04.02.2010 14:34 > > Bitte antworten an > > "Tapestry users" <users@tapestry.apache.org> > > > > > > An > > Tapestry users <users@tapestry.apache.org> > > Kopie > > > > Thema > > Multiple configuration items per service > > > > > > > > > > > > > > Hi, > > > > I have a use case where i want to provide to my service a white list + a > > black list of patterns.This list must be extensible by the service user > > via > > a contributeXxx method. > > The DefaultModelDef does not allow this. > > I guess this is a design choice, but is it reasonnable to say that the > > contributeXxx should have as many configuration parameters as the > service > > constructor to accept the contribution method ? > > > > Regards, > > Christophe > > > > > > -- Regards, Christophe Cordenier. Developer of wooki @wookicentral.com