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.

Reply via email to