> 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”. All 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
