A couple of things:
- UsingFactory: it should be able to use functions with parameters.
These parameters would be the dependencies of the component. I've got a
(phenomenally hacky) implementation of this if anyone's interested.
- It should be possible to specify dependency values as things other than
strings. I recognize that has *huge* implications. I know there are
ways around this, but they're not elegant.
- Personally, I hate attribute registration. I'd rather concentrate on
conventions. Now, if the convention stuff could allow you to specify how to
use attributes, that'd be extremely powerful. You could, for instance,
configure Windsor to use an existing assembly instrumented for StructureMap.
- +1 for Craig and Krzysztof's idea about context registration.
- +1 for environmental deltas. If it was important enough to add to
Binsor, it's important enough for the main product.
- +1 to consolidation. I don't know of anyone who finds the distinction
useful.Julian. 2010/1/21 Alwin <[email protected]> > inline: > > 2010/1/21 Krzysztof Koźmic (2) <[email protected]> > >> Alvin, >> >> >> Problem is this approach won't work when matching constructor >> parameters, and it changes semantics of the dependencies. >> >> when you specify just a name with string, you're being implicit about >> what kind of dependency it is (property or method argument) and let >> Windsor figure it out. >> Indeed depending on which constructors Windsor can satisfy, the same >> call can lead to having the dependency injected as ctor arg, and other >> time as property. >> > > You mean that when registering, it does not matter if the dependecy is a > ctor arg or property, and that you want to keep it that way? I fully agree > with that. > > >> >> I think it's a great strength of Windsor, and I much dislike being >> explicit about it when dealing with some other containers. You could >> provide certain strongly typed helpers via extension methods but I'd >> vote for not including that in the core API. >> > > Well the first link (on the using site) does indeed only work for > properties and then you get the difference between prop and ctor arg. I can > understand if you don't want to make that difference (and also don't want to > encourage property dependencies maybe). And therefore not include this in > the core MK/Windsor. > > But the second link (google user group) does not make a distinction between > ctor arg and property. It does however rely on reflection during > registration, which IMO is not great. It would be nicer to streamline it > with string-based service overrides. > But really all it does is change this: > > Component.For<Foo>().ServiceOverrides(ServiceOverride.ForKey("paramName").Eq("dependency")) > Into this: > > Component.For<Foo>().ServiceOverrides(ServiceOverride.ForType<IDependency>().Eq("dependency")) > > BTW this does blow up when having multiple dependencies of the same type. > But as long as you get a clear error message that should be fine. > > >> >> Krzysztof >> >> PS, >> thanks for improving the docs! >> > > You're welcome! > > >> >> On 21 Sty, 16:40, alwin <[email protected]> wrote: >> > I would really like to configurate components more strongly typed than >> > using strings for parameters and service overrides. >> > >> > I've made stuff in the past but it's more bolted on top of MK than >> > nicely integrated into it: >> http://using.castleproject.org/display/IoC/Strongly+Typed+property+wi...http://groups.google.com/group/castle-project-users/browse_thread/thr. >> .. >> > >> > Something like this would be great: >> > >> > // Use registration model as value for service override >> > var dependency = container.Register >> > (component.For<IDependency>..config...) >> > container.Register( >> > Component.For<IConsumer>().ImplementedBy<TheConsumer>() >> > .ServiceOverrides(ServiceOverride.For<IDependency>().Eq >> > (dependency)) >> > ); >> > >> > or even: >> > // Easier discoverability when using intellisense? >> > container.Register(register => >> > register.ComponentFor<IConsumer>().ImplementedBy<TheConsumer> >> > () >> > .ServiceOverrides(s => s.For<IDependency>().Eq >> > (dependency)) >> > ); >> > >> > If you guys are into this I can try to provide some patches (no >> > promises...). >> > >> > On 21 jan, 15:32, Richard Fleming <[email protected]> wrote: >> > >> > > That was why in this case I would suggest creating a method to allow >> the >> > > user to register interface types which they would like to be their >> > > registerable interfaces, I wouldn't want to force that on users >> either, just >> > > in my case wasn't necessary since my interface exists in the same >> project as >> > > the functionality :) . >> > >> > > On Thu, Jan 21, 2010 at 8:29 AM, Ayende Rahien <[email protected]> >> wrote: >> > > > I wouldn't like to have something like this for the simple reason >> that I >> > > > want to avoid forcing people to implement my interface. >> > >> > > > On Thu, Jan 21, 2010 at 4:21 PM, Richard Fleming < >> [email protected]>wrote: >> > >> > > >> Just as an alternative method to a [Service] attribute I do >> something >> > > >> along the following in most of my projects now: >> > >> > > >> public interface IRegisterable { } >> > > >> public interface IRegisterableWithFactory : IRegisterable { } >> > >> > > >> public static class WindsorExtensions >> > > >> { >> > > >> public static BasedOnDescriptor FirstInterfaceOnType(this >> > > >> ServiceDescriptor serviceDescriptor) >> > > >> { >> > > >> return serviceDescriptor.Select((type, baseType) => >> > > >> GetInterfacesOnType(type)); >> > > >> } >> > >> > > >> private static IEnumerable<Type> GetInterfacesOnType(Type >> type) >> > > >> { >> > > >> var interfaces = >> > > >> type.GetInterfaces().Except(type.BaseType.GetInterfaces()); >> > > >> return interfaces.Count() == 0 >> > > >> ? (typeof(object).Equals(type.BaseType) ? >> null : >> > > >> GetInterfacesOnType(type.BaseType)) >> > > >> : new[] { interfaces.First() }; >> > > >> } >> > > >> } >> > >> > > >> public DefaultContainer >> AddRegisterableComponentsFrom(Assembly >> > > >> assembly) >> > > >> { >> > > >> return >> > > >> AddRegisterableComponentsFrom(assembly.GetTypes().ToList()); >> > > >> } >> > >> > > >> public DefaultContainer >> > > >> AddRegisterableComponentsFrom(IEnumerable<Type> types) >> > > >> { >> > > >> Register( >> > > >> AllTypes.Pick().From(from t in types >> > > >> where !t.IsClass && typeof >> > > >> (IRegisterableWithFactory).IsAssignableFrom(t) >> > > >> select >> > > >> t).WithService.FirstInterfaceOnType().Configure( >> > > >> c => >> > > >> c.Attribute("instance-accessor").Eq("Instance"))); >> > >> > > >> Register( >> > > >> AllTypes.Pick().From(from t in types >> > > >> where t.IsClass && >> !t.IsAbstract && >> > > >> typeof(IRegisterable).IsAssignableFrom(t) && >> > > >> !typeof(IRegisterableWithFactory).IsAssignableFrom(t) >> > > >> select >> > > >> t).WithService.FirstInterfaceOnType()); >> > > >> return this; >> > > >> } >> > >> > > >> (DefaultContainer is my class inheriting from WindsorContainer >> where I >> > > >> configure facilities outside of configuration) >> > >> > > >> What I liked about this method was it allowed me to control >> > > >> auto-registration by having a custom interface defined (and >> typically >> > > >> creating an AbstractComponent or something of that sort which >> implements >> > > >> IRegisterable). >> > >> > > >> Just thought I would throw this out there as another alternative, I >> was >> > > >> thinking along the lines of possible if there was a way to register >> a >> > > >> interface type(s) as the "auto-registering" (IRegisterable in this >> case) >> > > >> within the container to make the functionality more general across >> multiple >> > > >> projects. >> > >> > > >> Thanks, >> > > >> Rick Fleming >> > >> > > >>> > - Consider adding attributes like [Service] - to make auto >> > > >>>> registration >> > > >>>> > easier. >> > >> > > >>>> +1 >> > >> > > >>>> > - Convention based registration for fluent stuff >> > > >>>> > - IFoo -> Foo >> > > >>>> > - IFoo -> FooImpl >> > > >>>> > - IFoo -> FooService >> > >> > > >>>> - I'm not sure what you mean by that... >> > >> > > >>> contianer.AddAssembly("foo"); >> > >> > > >>> - scan for all interfaces >> > > >>> - for each interface, look for a matching type based on the >> following >> > > >>> naming conventions, if exists, register it. >> > > >>> - same for types marked as [Service] that implement only one >> interface >> > > >>> - if there is more than one interface implemented, require a >> interface >> > > >>> parameter on the attribute. >> > >> > > >> -- >> > > >> 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]<castle-project-devel%[email protected]> >> <castle-project-devel%[email protected]<castle-project-devel%[email protected]> >> > >> > > >> . >> > > >> For more options, visit this group at >> > > >>http://groups.google.com/group/castle-project-devel?hl=en. >> > >> > > > -- >> > > > 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]<castle-project-devel%[email protected]> >> <castle-project-devel%[email protected]<castle-project-devel%[email protected]> >> > >> > > > . >> > > > For more options, visit this group at >> > > >http://groups.google.com/group/castle-project-devel?hl=en. >> > >> > >> >> -- >> 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]<castle-project-devel%[email protected]> >> . >> >> For more options, visit this group at >> http://groups.google.com/group/castle-project-devel?hl=en. >> >> >> >> > > -- > 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]<castle-project-devel%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > >--
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.
