That was extremely helpful. I think I've got some idea of how LifestyleManagers fit into component resolution now, and it's sufficient to solve this problem.
Thank you very much! On Mar 3, 8:52 pm, Germán Schuager <[email protected]> wrote: > Hi, I got a bit lost in your post :) but I will point you some things that > may be useful (or not at all). > > I've wrote a custom contextual lifestyle.. the info is > here:http://blog.schuager.com/2008/11/custom-windsor-lifestyle.html(I'm not > happy with this implementation) > > <http://blog.schuager.com/2008/11/custom-windsor-lifestyle.html>Then I've > continue doing some experiments and reach something that pass these tests > (and others):http://gist.github.com/320996 > > If you are interested in this just ping me. > > On Wed, Mar 3, 2010 at 2:26 PM, Alex Davidson <[email protected]>wrote: > > > Hi, > > > I'm not sure how to accomplish this, but I suspect it will eventually > > involve lifestyles and child kernels: > > > interface IIndexSchema<TKey> { } > > > interface IIndex {} > > interface IIndex<TKey> {} : IIndex {} > > interface IIndex<TKey, TSchema> : IIndex<TKey> where TSchema : > > IIndexSchema<TKey> > > { > > TSchema Schema {get;} > > } > > > interface IIndexFactory > > { > > IIndex<TKey, TSchema> Create<TKey, TSchema>(); > > } > > > interface ITask<TKey> { } > > > interface ITaskQueue<TKey> > > { > > void Enqueue<TTask>() where TTask : ITask<TKey> > > } > > > Each IIndex<TKey, TSchema> should be a singleton. Its implementation > > depends on many other components; these should be instantiated once > > for each IIndex<TKey, TSchema> (and may depend on each another too). > > One of IIndex's dependencies is ITaskQueue. It must be able to resolve > > TTask, injecting component instances from its IIndex's scope where > > possible. > > > What I do right now is create a child kernel for each TSchema, > > registering certain components in it (including the IIndex<TKey, > > TSchema>, just to make things fun), then registering the IIndex<TKey, > > TSchema> in the parent kernel/container too (currently done by > > delegating to that TSchema's child kernel via a factory method). > > > And now I'd like to be able to add additional interfaces with TSchema > > type arguments alongside IIndex<TKey, TSchema> in the parent > > container, and have them get per-TSchema instances where possible > > too... > > > So...would this be better handled with a LifestyleManager of some > > sort? > > > I'm guessing it'd be necessary to gather all the generic arguments > > from the service being instantiated (including gen args of its gen > > args if present) to find something matching a TSchema. Then would I > > need to set that in the CreationContext for the component? Would that > > information still be present when resolving subdependencies too? If > > they're set to be per-TSchema they'd have to be selected based upon > > the schema of whatever depends on the thing that depends on them, etc. > > There needs to be a way of injecting context into a component instance > > too (ITaskQueue<TKey>, specifically), such that it can ask for an > > ITask<TKey> implementation and get it resolved with components for its > > owning TSchema if possible. Could that be done by providing > > ITaskQueue<TKey> with something akin to ITypeResolver<TSchema> to > > capture the context, or is there a better way? > > > Am I right about any of this, or am I heading down another blind > > alley? The Windsor docs on implementing facilities and lifestyles seem > > to be rather sparse, or maybe I'm looking in the wrong place. For > > instance, what is the lifecycle of a CreationContext? > > > Thanks! > > > Alex Davidson > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Users" group. > > To post to this group, send email to [email protected] > > . > > To unsubscribe from this group, send email to > > [email protected]<castle-project-users%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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-users?hl=en.
