inline ;-) 2010/1/21 Ayende Rahien <[email protected]>
> inline > > 2010/1/21 Krzysztof Koźmic (2) <[email protected]> > >> 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... >> >> > I think it is a useful thing to have, and I have needed it a time or two in > the past. > I agree there is a demand for this > > >> > - 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 >> >> > I like the idea of IWI, my point is that we need to communicate that it is > the standard way of doing this. > This is definitely the corollary to Modules and Registries. It is how binsor is currently integrated into container As Ayende mentioned, its just not well explained or recognized > > >> > - 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. > So this would be just another strategy (like AllTypes) for the fluent registration. container.Register(Conventions.ForAssembly("foo")) > > > >> > - 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. >> >> > I think we are better with the limitation than without it. Moreover, that > would allow us to throw when you are using narrow scoped dependency on wider > scope dependency. > I run into some interesting bugs when I didn't caught that. > +1 > > >> > - 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? >> >> > I am in favor of doing that, yes. > Definitely in favor. > > Please note that this is a breaking change. > I think we should consider this to be a 3.0 version, and accept the > potential breaking changes. That would also allow us to perform the cleanup > for the API. > > >> > >> > 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]<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.
