moreover - something similar to StructureMaps AssertConfigurationIsValid/ WharDoIHave (although I would have this in external service, not the container itself) - build in some diagnostics into the container, even if just the basic one... similar to how its done in DynamicProxy or NHibernate...
On 22 Sty, 08:44, Krzysztof Koźmic (2) <[email protected]> wrote: > 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 1/4 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.
