Additional ones that I talked with Krzysztof about are - Allow the Fluent Registration to attach to an new ComponentModel created during registration (usually from ComponentModelCreated event). This will give Facilities an much simpler an consistent approach to manipulating the models and would likely use the extensions fluent api discussed below - Better unify the ability to create contextual lifestyle managers. This is such a common use case and every different context seems to produce a different approach. NHibernate context, WCF Context, ..... It should make supporting new context simpler - Provide more integrated support for contextual resolution without having to register IHandlerSelectors directly (like Ninject does)
2010/1/21 Krzysztof Koźmic (2) <[email protected]> > 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]<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.
