Essentially take those graphs I made, then replace DependencyMap with the interceptor pattern of doing things. Could also see it as a chain or pipeline. Right?
When generalized, this probably adds quite a bit of complexity to the container and maybe quite a bit of slowdown as well during lookup. Also, conceptually replacing "a simple, one-method, one-arg, hash-backed lookup()" with a "chain of responsibility to satisfy any style of lookup()" is pretty bad. So I would not generalize it. Then it can have obvious advantages. regards, - Leo > I remember the suggestion - but I'm thinking about this differently in > terms of an interceptor architecture. Basically, an interceptor > approach on a container would provide a more general solution to > componet selection that Leo and I were discussing. My current working > solution is to locate a selector using a pluggable service class > selector (which was easy to do but has many restrictions) - and Leo > specifically wanted to things that went beyond service type. Adding the > notion of an interceptor chain between the container and any client of > the container (e.g. a component manager/locator) would enable a lot more > flexibility and would alow things like a component transaction to be > hidden within an interceptor implementation. It would also open up a > lot more flexibility in terms of strict compliance with formal component > contracts - i.e. an ECMInterceptor could handle parsing and > interpritation of a Cocoon style lookup, handle all of that stuff > related to hints selectors etc. - effectively seperating the Cocoon > usage model from the container. As to the pooling stuff - I don't have > a good idea of what that would involve but I have a hunch that it could > be practicel approach - at least it would be interesting to get > throughts in this from members of the list that are heavily into pooled > objects. > > Cheers, Steve. > > p.s. Can you do me a favour and repost the earlier message concerning > (Component)Transaction. > > SJM > > > > > > > Cheers, > > > > Peter Donald > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > "Faced with the choice between changing one's mind, > > and proving that there is no need to do so - almost > > everyone gets busy on the proof." > > - John Kenneth Galbraith > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > Stephen J. McConnell > > OSM SARL > digital products for a global economy > mailto:[EMAIL PROTECTED] > http://www.osm.net > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
