Yea, I thought of making the 1st factory a concrete class, but I couldn't come up with an elegant way to have it resolve the 2nd factories from the container when the CreateFactory method is called.
If you have a thought on a resolution approach, I'd love to hear it. I'm going to try hacking around with adding some kind of statefullness to the typed factory, and see if it's worth a closer look. -r 2011/7/22 Krzysztof Koźmic <[email protected]> > Hmmm > > that is interesting. In general, Typed Factories were meant to be > stateless, I can see value in this scenario, just I'm not sure what would be > an elegant way to support it. > Why don't you just make the first factory an actual class, and for the > second one use a typed factory? > > > > On 22/07/2011 6:33 AM, Rory Plaire wrote: > > As to why: here is the question I posted on SO - > > http://stackoverflow.com/questions/6772484/castle-windsor-passing-a-dependency-through-2-typed-factories > > Summary: I want to create a typed factory from another typed factory but I > want to add a dependency to the resolution context of the 2nd typed factory. > > I wanted to put an interceptor after the resolution of the 1st typed > factory in order to contribute this dependency to the context. > > As to ExtendedHandler - it appears that the typed factory uses this as the > handler to invoke the chain of invocations, which is why I thought it would > work fine to just add another after the resolution was done in the typed > factory interceptor, if the interceptor just called Proceed(). > > -r > > 2011/7/21 Krzysztof Koźmic <[email protected]> > >> As far as other interceptors are concerns the factory interceptor _is_ >> the implementation. You can put other interceptors before the factory one. >> >> Extended handler has no role in that process, it does something else >> altogether. >> >> Why would you want to put anything past the factory interceptor? >> >> Krzysztof >> >> >> On 21/07/2011 4:59 PM, Rory Plaire wrote: >> >> 2011/7/20 Krzysztof Koźmic <[email protected]> >> >>> of course it doesn't. There's no implementation to proceed to >> >> >> Indeed, of course... but this also precludes chaining subsequent >> interceptors. However, doesn't the ExtendedHandler take care of not needing >> an actual instance to proceed to? >> -- >> 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. >> > > -- > 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. > -- 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.
