Hi Massimo, thanks for the reply. Unfortunately neither of these patterns works for me because they rely on the chained service(s) being instantiated in the normal way, ie. via bind or build.
Looking at DefaultModuleDefImpl there doesn't seem any reason in principle why it's too early in the bind() method of a module to late bind an implementation class based on a symbol. Or alternatively have a special form of buildXxxxx which supports this kind of thing, ie. allowing the builder to return a service definition rather than a concrete class via new. Am still looking through the sources to see what might be possible/simple. Unless I'm missing something I don't think what I'm after can be done without a change to Tapestry. Anyone disagree? Do people think this is this a reasonable feature request? Regards, Alfie. -----Original Message----- From: Massimo Lusetti [mailto:mluse...@gmail.com] Sent: 14 July 2009 13:47 To: Tapestry users Subject: Re: Dynamic service binding based on symbol source On Tue, Jul 14, 2009 at 2:43 PM, Alfie Kirkpatrick<alfie.kirkpatr...@ioko.com> wrote: > I would like to instantiate a different service implementation depending > on property file configuration, eg. a stub for testing and a real > service for deployments. I'd like to put the FQN in my property file > which is then wrapped in a SymbolProvider. I highly suggest you to build a chain of command or a strategy pattern depending on service type and let the IoC do the work for you. -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
