Taking greater advantage of the container when extending it

[Mogens Heller Grabe]

Inspired by a suggestion on uservoice, I have hacked together a simple POC of a facility that allows for handler selectors/filters to be pulled from the container (via new ISelectHandlerFor<TService> and IFilterHandlersFor<TService> service interfaces).

Can anyone see any issues with extending the container like this?

Could this perhaps be a way to support putting the container to more use in the future without sacrificing backwards compatibility?

I am very curious to hear if anyone has comments or suggestions for this.

You can see the code (and some snippets) on my GitHub.

[Krzysztof Koźmic]

Hi Mogens,

I gave this issue a bit of thought myself, and the main problem I found is the chicken and egg problem.

Also it's hard to handle recursive behaviour elegantly.

We have one type of components that do that right now - ILazyComponentLoaders which are registered as normal components (and also interceptors to a smaller degree), but handling this in a generic, and robust way is going to be a sizeable task IMO.

Having said that - I'm keen to get more input and ideas on this.

Krzysztof

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-devel/-/pI9QqMltGIQJ.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[Mogens Heller Grabe]

But I think I handled the chicken-and-egg problem in a pretty simple way - my selector/filter simply looks for the presence of the given service type in a bag, to determine if it should look up a selector/filter from the container. The bag is built by hooking into the ComponentRegistered event on the kernel.

When I implemented handler filters, I also got the impression that modifying this part of the container would be kind of tedious - therefore, I'm now proposing a solution that builds upon the existing behavior, without modifying a single line in the container.

My initial thought was to make this available as a facility (which is what I have done now), but if it proved useful then we could perhaps consider adding the behavior provided by the facility to the container per default.

[Mogens Heller Grabe]

If you're feeling fresh and energetic, I would be extremely happy if you'd take a quick look at FtwFacility.cs and Ftw.cs and see if I made any rookie mistakes ;)