Julian,That is all user configurable right now with the use of IHandlerSelector
On Wed, May 20, 2009 at 2:38 PM, Julian Birch <[email protected]>wrote: > Okay, that should get people's attention. ;-) Krzysztof originally > suggested this > here<http://kozmic.pl/archive/2009/04/09/convention-based-dependency-injection-with-castle-microkernelwindsor.aspx>, > and it's received a fair bit of support on User Voice. I said I'd write up > the issue for the dev list. Now, the subject of convention over > configuration is huge, but this is going to concentrate on one particular > issue. I'd very much like the developers's opinions. > Now, taking the example right at the start of Krzysztof's post, there are > two things I want to discuss. The first is the behaviour when you call > > kernel["generator"] > > and the other when you call > > kernel.Resolve<IAlarmSender>. > > In the first, I'm going to say we're resolving an ambiguous dependency, in > the latter, an ambiguous reference. (Sorry if I'm using the wrong terms > here.) > > Now, there are a number of ways that we could resolve this: > > - First Registered (The current behaviour) > - Use a convention on the basis of the parameter name (The behaviour > Krzysztof > suggests, only applicable to dependency resolution) > - Select if a secondary (marker) interface is present. (Useful if one > object aggregates the others, but not appropriate as a default.) > - Throw An Exception (I actually quite like this idea. I'm pretty > sure Krzysztof hates it.) > - Something I haven't thought of. > > These behaviours could be chained (try parameter name convention, then > marker, then throw an exception). Example syntax (for illustration only): > > container.Register(DependencyResolution.Using( > X.ByParameterName, > X.ByMarkerInterface<IAggregate>(), > X.DontResolve > )); > > I believe it wouldn't be too hard to support this with a patch to the ( > believe, I haven't actually tried coding it yet... :) ). > > Questions: > > 1. Should the current behaviour of resolving ambiguous dependencies be > changed? > 2. If so, what should be the new default? > 3. What's it going to break? > 4. Same question again for ambiguous references. > 5. Should we add in a syntax for pluggable behaviours for resolving > ambiguous references/dependencies? > 6. What conventions should we support? > 7. What's the syntax for XML, Binsor? I'm assuming at the moment that > we'd allow customization of behaviour through a built-in facility. > 8. What constitutes an ambiguous reference/dependency? > > Obviously, the answers to some questions affect the answers to others. > > For clarity, my answer to 8) is: > > - Where there is no service override > - Where there is no suitable parameter passed to Resolve > - Where two components are registered for or forward the same service > type > - Implementations of the service type not registered as such are not > counted > - Implementations of the service type through proxying not > registered as such are not counted > > Apologies if this isn't clear, or I missed an important aspect of the > pipeline. > > Julian. > > P.S. I've come to the conclusion that my convention proposal on the > UserVoice list is compatible with this one, I'll come back with that when > I've got a more developed proposal. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
