Hi Achim,
Thanks for the feedback. Some comments:
On 8/6/06, Achim Hügen <[EMAIL PROTECTED]> wrote:
some general remarks:
1. Associations:
I'm missing the associations between related items. For example
between a service point and its implementation(s) or a configuration
and its contributions. I'd distinguish between directly resolvable
extension (inside the same module) and "unresolvable" extensions that
contribute to external modules.
For resolvable extensions I regard it as more intuitive and OO to
offer an api that represents the module as object graph:
ModuleDef module = new ModuleDefImpl("module1");
ServicePointDef sp = new ServicePointDefImpl("Service1", module);
module.addServicePoint(sp);
sp.addImplementation(..));
sp.addInterceptor(...)
vs.
ModuleDef module = new ModuleDefImpl("Module1");
module.addServicePoint(new ServicePointDefImpl("Service1", module));
module.addImplementation(new ImplementationDefImpl("Module1.Service1", ..
));
module.addInterceptor(new InterceptorDefImpl("Module1.Service1", ... ));
By the way, what about the 'add' methods, shouldn't they be included in
the interfaces?
Yes and no. I feel that the API, i.e. the *Def interfaces, should only
represent the requirements from HiveMind's point of view and not
contain methods that the implementation (e.g. Java or Java annotations
based support) will need. This should however not prevent the
implementation from defining such methods. I.e. your example for what
the Java based support implementation could look like should still be
simple to implement in terms of the proposed API.
> - Note the plural form in ContributionsDef. This signifies that a
> ContributionsDef can contribute multiple elements to a configuration
> point. I don't know what methods ContributionsConstructor should
> declare.
IMO it's very important for java based and annotation based modules, that
we get rid of the 'configuration is always a list or map' limitation.
Hence I defined a ConfigurationConstructor that constructs the container
element (today it's a list):
public interface ConfigurationConstructor extends Locatable
{
public Object constructConfigurationContainer(Module module);
}
and the ContributionsConstructor gets the container handed in and
can add items, set properties or whatever he want's to do with it:
public interface ContributionConstructor
{
public void contribute(ConfigurationPoint configurationPoint, Object
container);
}
That looks interesting. That would of course mean that a configuration
is always just available as one type of "container". But that seems
like a reasonable restriction and a backward incompatibility we could
justify.
I just wonder if this has any implications for the proxying and
autowiring. Should the ConfigurationPointDef maybe, just like the
ServicePointDef with getServiceInterfaceName(), expose the container
type with a getContainerInterfaceName() method. This would probably be
required for HiveMind to be able to create a proxy for the
configuration. We can also take a peek at Tapestry IoC's approach
(currently limited to unordered, ordered, and mapped configurations)
for ideas:
http://svn.apache.org/viewvc/tapestry/tapestry5/tapestry-core/trunk/src/main/java/org/apache/tapestry/ioc/def/ContributionDef.java?view=markup.
--knut
