If you create a MappedConfiguration<String,LicenseGenerator> you will end up with a configuration backed by a map of name->impl.
In your service you inject the mapped configuration, check to see if the configuration contains a generator for your "string" and use the impl if that is the case There are many internal tapestry services that uses this pattern, so I suggest you check out the source and see how they are created. (NullFieldStrategySourceImpl and related code could be an example) -- Chris On Mon, May 9, 2016 at 9:22 AM, Rafael Bugajewski <raf...@juicycocktail.com> wrote: > > On 2016-07-05, at 09:48 AM, Chris Poulsen <mailingl...@nesluop.dk> > wrote: > > > > It is not really clear to me what you want to do? Are you talking about > > picking the correct impl once (during initial application setup) or > > selecting the impl. per request. Is the "input parameter" something that > is > > defined during registry bootstrap or passed in on every call? > > The “input parameter” is something that is passed in on every call and > from which I would have to create a mapping for and which then would > instantiate the corresponding service. It’s just a string that represents a > product + product version. > > > For the latter you could create a map configuration (name->impl), inject > > that into your service and lookup the named impl. at run time. > > > But wouldn’t this mean if-else blocks in the service where I lookup the > implementation depending on my input? > > > On 2016-08-05, at 01:41 PM, Barry Books <trs...@gmail.com> wrote: > > > > Then I would use a strategy service to actually do the work by passing in > > the class. This service can be used by the previous service so the > > Generator service just takes a string and returns the license interface. > > If I understand things correctly (and I’m not sure, that’s why I ask) then > the strategy builder service would be the missing link in my desired > implementation? I already read about it in the official Tapestry User Guide > (https://tapestry.apache.org/strategybuilder-service.html), but the > documentation is rather sparse. I found another article at > http://blog.tapestry5.de/index.php/2010/05/20/advanced-service-builders-in-tapestry-ioc-strategy-pattern/ > that gives an example. From this quote I would think that a strategy > builder service is the way to go in my case: > > > The StrategyBuilder service creates an implementation which uses all the > configured strategies behind the scenes. It executes all the ugly > if-else-statements for you. It analyzes the first parameter of each service > method to select the appropriate strategy. > > That’s basically what I want (or at least think I want). Ideally I would > supply Tapestry with a mapping “input parameter” → “instance”. A ll of the > instances would implement the same interface and represent different > products / license generation schemes. I would just call the LicenseService > which then – with the help of some Tapestry magic – would discriminate > based on an input parameter and hence “automatically” call the right > implementation. > > Does this clear some things up? With my current Tapestry knowledge and > thanks to the help of Chris I would probably add a configuration to my > service. Then I would check the configuration with if-else blocks and > return the correct instance. I just wonder where the strategy pattern fits > in (if it fits in at all?) and if it could help me to save some LOCs? > > Best, > Rafael > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
