I was going to reply you via email, but this is better :) Assuming we're talking about Windsor 2.2 (minor version) Here are some of my ideas (and not only mine, but ones I'd like to add)
- ability to override in-code registration with XML (env deltas) - improve event wiring facility (add actual registration API, perhaps some convention based wiring as in Mike's post: http://mikehadlow.blogspot.com/2010/01/10-advanced-windsor-tricks-7-how-to.html) - create .NET 4.0 and SL 4.0 version - support lazy initialization of components via Lazy<T> (for .NET 4.0 version) - check how co/contra-variance of generics may be taken advantage of and do it. - remove overloads that we're workarounds for lack of optional parameters (for .NET 4.0 version. This could be a breaking change so we might postpone it to next major version - 3.0) - split the fluent API into two - for end users, and for extensions, Remove OverWrite, ActAs and UsingFactory methods (perhaps make them obsolete for now not to break anyone who uses them). - make UsingFactoryMethod in fluent API not depend on factory support facility and just use custom activator - remove startabe facility's method from general fluent API, and move them to extension methods living in the facility's namespace, similar to how it's done in Typed Factory Facility and WCF Facility - get rid of the arbitrary division for Service/Parameter dependencies, which is leaky and confusing: http://stackoverflow.com/questions/1839199/how-to-register-a-uri-dependency-to-return-httpcontext-current-request-url-using probably more... that's just from the top of my head. 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). > - 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 > - Consider adding attributes like [Service] - to make auto registration > easier. > - Convention based registration for fluent stuff > - IFoo -> Foo > - IFoo -> FooImpl > - IFoo -> FooService > - Generate proxies to match up lifestyles of components that have > different life styles. > - 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 > - Consolidate the Windsor & MicroKernel assemblies, I don't see a good > reason why we still have this split between them. > > 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.
