James,
It's not quite clear to me which problems you are trying to solve with
the transformers. Is it an additional feature?
Your proposal would limit the contributions to lists again. This
limitation doesn't
feel natural in the annotation world. Here is another example which
shows how to use a more complex object as container.
public class ExampleModule
{
@Configuration(id = "strutsModule")
public ModuleConfig getStrutsModule()
{
return new ModuleConfigImpl();
}
@Contribution(configuration-id = "strutsModule")
public void contributeToStrutsModule(ModuleConfig config)
{
config.addActionConfig(new ActionConfig());
config.addFormBeanConfig(new MyFormBeanConfig());
}
}
Achim
James Carman schrieb:
Well, how about this for the configuration/contribution stuff? We
introduce the concept of a ContributionTransformer (to borrow a term
from commons collections):
public interface ContributionTransformer
{
public Object transform( List contributions );
}
Each configuration point can have a ContributionTransformer assigned
to it. It uses this to transform its contributed objects into the
desired type. The default one would just return the list of original
objects, but you can assign your own like this:
<configuration-point id="blah"
transformer="instance:com.myco.MyContribTransformer">
...
</configuration-point>
We could provide a couple of useful helper classes like
SingleContributionTransformer which merely returns the first item in
the list.
Also, we could do a MappedContributionTransformer which
transforms a list of MappedContribution objects (name/value pair
essentially) into a HashMap (or you can specify another Map subclass
if you like). This would allow us to support single-value
configurations easier, because they wouldn't have a "container class."
On 11/7/06, Achim Hügen <[EMAIL PROTECTED]> wrote:
Hi,
I've finished a short overview of the changes in the annotation branch:
http://wiki.apache.org/jakarta-hivemind/NewAndNoteworthyFeaturesInAnnotationBranch
Have fun
Achim
