On 11/03/2011 4:15 PM, hammett wrote:
" since when using the factory we've already lost the clear graph boundary, so implicit scoping like this should not be supported."Yeah I wasn't clear. I was talking about a specific subset of scenarios where we want to tie instance of one component (let's say ISession so that we don't talk very abstract terms) to another component (let's say Screen). That means that whenever we're resolving a graph and Screen is part of the graph, whoever uses ISession in the sub-graph rooted by Screen will get the same instance of ISession.I'm not sure I understand.
So let's say we're in a WinForms app and we have a Shell object that is the root and main window of the app and it has a IEnumerable<Screen> as its dependency. Each screen will be scoping the new instance of ISession, but the screen itself doesn't need to have direct dependency on ISession. It can be screen has a Logger and Logger uses session to log to a database, or screen has tabs and those tabs use session to load some data.
For the lack of better word I call ISession tentatively a graphed component. It is ISession that decides it wants to be available in certain subgraph, and it is it, that designates the scoping root within that sub-graph.
The thing where typed factories come in is for scenarios like the following:screen wants to open a file so via factory it resolves a file-displayer (say TextFileDisplayer, XmlDisplayer, JpgDisplayer... you get the idea). What I was thinking about is what should we do when something in the displayer's graph wants an ISession. Should we consider the Screen, being (perhaps indirect) upper branch of the factory in object's composition tree, the root of that ISession's scope? That might seem nice, from the API perspective so users might expect this to work OOTB. However for the reasons I outlined in the wiki (the factory instance can be shared across multiple screens plus it has no way of knowing what its root is anyway without heavy hackery) I don't think that's possible/feasible without using explicit (not graphed) scoping.
Hope that clears things a bit. I'm still in early stages of thinking about it, so I'm happy for my ideas and approach to be challenged and discussed. Would also be great to get Craig, who I know had been using scopes in production already, and Mauricio and German who I believe have too, to contribute to this discussion.
Yeah, I hope the above clears this a bit. I will probably expand and clarify it in the wiki too tomorrow.Besides, I think you've a solid idea on what's scoping in your world. I'm not sure I'm on the same page... (communication breakdown, maybe?)
Right, yes I agree, I'm just too lazy to type all that stuff in :). At this early stage I start with one scenario (similar to the one above) and then from there try to come up with variations that people will want to use, just because they can, and then from there try to get a different angle at the problem. I do agree that the more real life scenarios we have the better though.Also, while you make reference to scenarios, there are no scenarios listed. Scenario would be "App needs to create DocWindow", something that I can easily relate to. That would improve communication of your proposal/ideas.
Factory wasn't meant to be a scope entry point as I described above. This is talking about subset of cases we want to support. We do need (and already have, look at the tests) explicit scopes too, however my last email was discussing only implicit scoping.Finally, I don't see typed factories as entry points to scope. I see a specific typed idiom instead. IMHO scopes should be properly designed, as they have major side effects on the system behavior. So I wouldnt use Func<T>, but something very explicit about its intention.
This is going to be the role of ICurrentScopeAccessor implementor which depending on where the IScopeCache is stored will have to handle access to the cache and optionally be thread safe. The cache itself will also have to be thread safe (actually we may have two implementations and use the one that fits... we'll see about that)Additionally, IoC Containers cannot be replacement for OO. Some things fit containers, some can't. This is just general advice that sparked after reading this:* Ensuring scoping works (can work?) across multiple threads
* Ensuring scoping works across multiple objects. Going back to
WPF application's example we may want to be able to gain access
to current's top window's |ISession| from static typed factory
residing in the root shell object.
yeah, that's on the radar too.
huh?! Do we need to pay you royalties for using scopes in Windsor now? ;) If you have a link I'd sure be happy to give it a read.I've filled a patent based on the result of my research on containers + scoping. I'd think it's already out there, you should probably give it a read :-)
Krzysztof
2011/3/10 Krzysztof Koźmic <[email protected] <mailto:[email protected]>>I added tests (in my fork) and discussion of potential usage of implicit scoping and typed factories. My conclusion is, it can't be done but I'm happy to be enlightened and convinced otherwise. http://docs.castleproject.org/Windsor.Scratchpad-scopes-in-Windsor-codename-Wawel.ashx?NoRedirect=1&NS=Windsor <http://docs.castleproject.org/Windsor.Scratchpad-scopes-in-Windsor-codename-Wawel.ashx?NoRedirect=1&NS=Windsor> Krzysztof On 09/03/2011 11:53 AM, hammett wrote:Interesting. Is there a variation that will allow a component to start/end a scope in runtime? Suppose you have a MDI app. Each File | New Document is potentially starting a new 'document' scope. 2011/3/8 Krzysztof Koźmic <[email protected] <mailto:[email protected]>> Hi, I created a site in the wiki where I'll throw my semi-structured thoughts and ideas for implementing one of the biggest new features for Windsor Wawel (aka vNext) - scoping. http://docs.castleproject.org/Windsor.Scratchpad-scopes-in-Windsor-codename-Wawel.ashx?NoRedirect=1&NS=Windsor <http://docs.castleproject.org/Windsor.Scratchpad-scopes-in-Windsor-codename-Wawel.ashx?NoRedirect=1&NS=Windsor> I would really appreciate if you guys shared your thoughts and ideas on this (it's an open wiki - go wild, contribute to the brainstorming). Also make sure you click the small semi-hidden envelope icon in upper right corner to subscribe to notifications of changes to the site. Thanks in advance for all your ideas and contributions. If we get this done, we should be pretty much ready to release first preview. cheers, Krzysztof-- You received this message because you are subscribed to theGoogle Groups "Castle Project Development List" group. To post to this group, send email to [email protected] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]>. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.-- Cheers,hammett http://hammett.castleproject.org/-- You received this message because you are subscribed to theGoogle Groups "Castle Project Development List" group. To post to this group, send email to [email protected] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto:[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 GoogleGroups "Castle Project Development List" group. To post to this group, send email to [email protected] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]>. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- Cheers, hammett http://hammett.castleproject.org/ --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.
-- 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.
<<image/png>>
