You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Rafael Bugajewski <ra...@juicycocktail.com> on 2016/05/06 17:49:10 UTC
What pattern to use for service disambiguation based on String input?
Hello,
I use tapestry-ioc in a Jersey JAX-RS application to access my Tapestry services. I have a LicenseService that generates a software license with the help of another service. This LicenseGeneratorService has implementations for different products Product1LicenseGeneratorServiceImpl, Product2LicenseGeneratorServiceImpl, ….
Based on a String input parameter I want tapestry-ioc to let the LicenseServiceImpl use the correct LicenseGeneratorService implementation.
What’s the cleanest way / pattern to approach this problem with the help of tapestry-ioc?
Best,
Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: What pattern to use for service disambiguation based on String input?
Posted by Chris Poulsen <ma...@nesluop.dk>.
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 <ra...@juicycocktail.com>
wrote:
> > On 2016-07-05, at 09:48 AM, Chris Poulsen <ma...@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 <tr...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: What pattern to use for service disambiguation based on String input?
Posted by Rafael Bugajewski <ra...@juicycocktail.com>.
> On 2016-07-05, at 09:48 AM, Chris Poulsen <ma...@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 <tr...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: What pattern to use for service disambiguation based on String input?
Posted by Barry Books <tr...@gmail.com>.
I usually use two services to solve this problem. First I create a service
that takes a string and returns an object. In your case I'd build a License
interface and the objects would all implement License. Most likely this can
be done with a service that takes a mapped configuration of String/Class<?
extends License>
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.
On Friday, May 6, 2016, Rafael Bugajewski <ra...@juicycocktail.com> wrote:
> Hello,
>
> I use tapestry-ioc in a Jersey JAX-RS application to access my Tapestry
> services. I have a LicenseService that generates a software license with
> the help of another service. This LicenseGeneratorService has
> implementations for different products Product1LicenseGeneratorServiceImpl,
> Product2LicenseGeneratorServiceImpl, ….
>
> Based on a String input parameter I want tapestry-ioc to let the
> LicenseServiceImpl use the correct LicenseGeneratorService implementation.
>
> What’s the cleanest way / pattern to approach this problem with the help
> of tapestry-ioc?
>
> Best,
> Rafael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> <javascript:;>
> For additional commands, e-mail: users-help@tapestry.apache.org
> <javascript:;>
>
>
Re: What pattern to use for service disambiguation based on String input?
Posted by Chris Poulsen <ma...@nesluop.dk>.
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?
For the prior I suppose you could use modules or symbols or a customized
build method.
For the latter you could create a map configuration (name->impl), inject
that into your service and lookup the named impl. at run time.
--
Chris
On Fri, May 6, 2016 at 7:49 PM, Rafael Bugajewski <ra...@juicycocktail.com>
wrote:
> Hello,
>
> I use tapestry-ioc in a Jersey JAX-RS application to access my Tapestry
> services. I have a LicenseService that generates a software license with
> the help of another service. This LicenseGeneratorService has
> implementations for different products Product1LicenseGeneratorServiceImpl,
> Product2LicenseGeneratorServiceImpl, ….
>
> Based on a String input parameter I want tapestry-ioc to let the
> LicenseServiceImpl use the correct LicenseGeneratorService implementation.
>
> What’s the cleanest way / pattern to approach this problem with the help
> of tapestry-ioc?
>
> Best,
> Rafael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>