What does the text "dooferController" represent in this context? Is it
> a string that represents the name of the service interface that you
> want to load? or is it a property in your page that holds a reference
> to the service implementation?
>
Sorry, my question probably wasn't very clear. Basically, the components we
are creating are intended to be reusable, and their behaviour is largely
defined by services they delegate to, as per your graphing example with the
BarChartService, PieChartService and ScatterPlotService.
In our product most of the tml is actually supplied by the user, and there
is no backing code for any of this tml in the conventional sense. When a
component is used, it's quite convenient to specify the implementation of
its backing service as a parameter, however, the only way I can see of doing
this is to introduce a new binding type, which in my example I've called
"service". The implementation of the sevice binding would ideally pull the
service out of the Registry.
The problem is when you get into the BindingFactory implementation:
@Inject Registry registry;
@Override
public Binding newBinding(
final String description,
final ComponentResources container,
final ComponentResources component,
String expression,
final Location location) {
// oops, how do i get the type?
registry.getService(expression, meh?);
}
So I appreciate that you could probably pass the service id and the service
type in the expression somehow, but that seems weak to me and wouldn't go
down well with our users.
As it happens, we had been passing the services into the components in a
different way previously, as we couldn't see a good way of achieving it via
parameters (for the previously stated reasons), but came back to it
recently. After posting the previous message on this forum, I had the idea
of doing the following, using a bespoke binding type I had already created
called factory.
The gist of this approach is to have 2 parameters, an internal parameter for
the actual service, where you specifiy both the service id and the parameter
type, and a public parameter for the service id (which gets fed into the
first parameter).
// the user specifies this...
@Property @Parameter(required=true, defaultPrefix="literal")
private String controller;
// this is a bespoke binding type, the user doesn't modify this parameter
@Parameter(defaultPrefix="factory", value="tapestry(" +
"id -> prop:controller," +
"serviceType -> prop:controllerType )")
private DataFormRendererController controllerService;
Which basically achieves what we want, but still doesn't seem very good - we
have to repeat this pattern for every component we have and require 2
parameters per service.
It just seems to me that being able to inject services out of the tapestry
registry into the components via parameters without having to perform any
special incantations would be a nice feature... but meh, what do I know
(apparently nothing).
Cheers,
Dave
--
View this message in context:
http://www.nabble.com/passing-a-service-into-a-component-as-a-parameter-tp25505462p25530329.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
