inline On 2010-01-21 18:33, Julian Birch wrote: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.
DependsOn can do it.
* 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.
Attributes have their place as well.
* +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] <mailto:[email protected]>> inline: 2010/1/21 Krzysztof Koźmic (2) <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]>. > > >> To unsubscribe from this group, send email to > > >> [email protected] <mailto:castle-project-devel%[email protected]><castle-project-devel%[email protected] <mailto: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] <mailto:[email protected]> > > > . > > > To unsubscribe from this group, send email to > > > [email protected] <mailto:castle-project-devel%[email protected]><castle-project-devel%[email protected] <mailto: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] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto: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 GoogleGroups "Castle Project Development List" group. To post to this group, send email to [email protected] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto: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.
--
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.
