Hi,
I've been thinking about the bootstrap procedure, and the now common
problem of assemblers having to take arguments for "visibility" (most
commonly), and how maybe it would be possible to separate those things
out.
One thing we did with layers and modules was to change from "addLayer"
to "layerAssembly", so that code could reference the same layer many
times without creating more layers. This is basically a declarative
rather than imperative approach. One might say: "duh".
How about we use the same for Module artifacts? Instead of:
module.addServices(SomeService.class,OtherService.class).visibleIn(Visibility.application);
we could do:
module.services(SomeService.class,OtherService.class).visibleIn(Visibility.application);
and then there would be no problem to do:
module.services(SomeService.class).identifiedBy("someservice");
With this in place we could then open up for specification-based
settings, such as:
// Expose all services in layer
module.services(Specifications.TRUE).visibleIn(Visibility.layer);
i.e. ModuleAssembly would have:
ServiceDeclaration services(Class<? extends ServiceComposite>... serviceTypes);
and
ServiceDeclaration services(Specification<Class> serviceSpecification);
or if we separate the current ServiceDeclaration so that it is the
fluent API only, and put the actual settings for a particular service
in ServiceAssembly, then it could be:
ServiceDeclaration services(Specification<ServiceAssembly>
serviceSpecification);
where the Specification could inspect any aspect of the current
assembly to figure out whether it should be worked on by the
ServiceDeclaration.
With this we would get a more declarative approach to assembly, and
can more easily separate various responsibilities and general
settings.
Whaddyathink?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
