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