Gauthier, Neat idea, but I'd rather see it "deeper in" the API, something like: AllTypes.Where(Component.HasAttribute(typeof(ServiceAttribute)))
Krzysztof On 22 Sty, 03:39, Gauthier Segay <[email protected]> wrote: > just a small idea: > > > > - Consider adding attributes like [Service] - to make auto registration > > > easier. > > > +1 > > container.Register(AllTypes.TaggedWithAttribute(typeof > (ServiceAttribute))) > > container.Register(AllTypes.TaggedWithInterface(typeof(IServiceTag))) > > On 21 jan, 14:54, Krzysztof Ko¼mic (2) <[email protected]> wrote: > > > About your ideas, inline > > > On 21 Sty, 13:57, Ayende Rahien <[email protected]> wrote: > > > > Now that a new version of Windsor is out, Krzysztof has brought to my > > > attention the need to plan the next version. > > > I thought about this for a while and I think that this is my initial list > > > of > > > things that I would like to see in the next version of Windsor. > > > > - InjectMembers(instance) - resolve dependencies on an existing > > > instance > > > without registering the type in the container > > > That would be useful for situations where the instance is created by > > > someone else (like the Page instance in ASP.Net WebForms). > > > I'm not a fan of this, but if there's demand... > > > > - Add something like StructureMap Registries, just to allow > > > standartized > > > approach to configue the container. > > > - inherit container ? > > > - facilities ? > > > - The goal here is just to have a standard recommended way of doing > > > it, rather than putting it in Application_Start > > > - with convention based fluent API, I don't see it as an issue. And we > > do have > > already ways of abstracting it, most notably IWindsorInstaller that > > work like > > Autofac's Modules and SM Registries AFAICT > > > > - 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... > > > > - Generate proxies to match up lifestyles of components that have > > > different life styles. > > > I thought about this as well, but then we bump into limitations of > > proxies plus that works only for interfaces. > > > > - So if I am singleton and depends on request scope stuff, I get a > > > proxy that match that up. > > > - Global settings - make it nicer to: > > > - Default Lifestyle setting > > > - Default disposable tracking setting > > > +1, we might also make it inheritable from parent container. > > > > - Consolidate the Windsor & MicroKernel assemblies, I don't see a good > > > reason why we still have this split between them. > > > +1. In this case there's no good reason to keep Core and DynamicProxy > > apart any longer either (main reason for this IIRC was so that > > MicroKernel does not depend on DP). > > Also do we want to really keep having two containers, or do we make > > IWindsorContainer inherit IKernel and merge DefaultKernel with > > WindsorContainer? > > > > Thoughts? > > -- 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.
