2011/3/10 Krzysztof Koźmic <[email protected]> > 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. >
The problem is expressing this, especially when the graph is complex. Is there any plans to define a blue print of graphs and interactions and hand it to a parent container, and a different one to a child container? > 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. > So here the problem is dynamic-ity vs static (?) > 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) > > 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. I'm not sure what's the role of the IoC Container here. I'd say that everything you outline is a general problem for OOP. Shouldn't be left in that domain then? > 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. No idea. IANAL :-) -- 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.
