You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Achim Hügen <ac...@gmx.de> on 2006/11/07 15:19:41 UTC
Changes in 2.0 branch
Hi,
I've finished a short overview of the changes in the annotation branch:
http://wiki.apache.org/jakarta-hivemind/NewAndNoteworthyFeaturesInAnnotationBranch
Have fun
Achim
Re: Changes in 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
The target type is determined by the transformer,
but it expects the source contributions as list doesn't it?
That would mean, that the contribution method in the example
below gets a List passed in as parameter?
Achim
Am Tue, 07 Nov 2006 17:28:12 +0100 schrieb James Carman
<ja...@carmanconsulting.com>:
> No, it doesn't limit it to lists. The list of contributions are
> "transformed" by the transformer into whatever is desired.
>
>
> On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
>> 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 <ac...@gmx.de> 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
>> >>
>> >>
>> >
>> >
>>
>>
>
Re: Changes in 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
No, it doesn't limit it to lists. The list of contributions are
"transformed" by the transformer into whatever is desired.
On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
> 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 <ac...@gmx.de> 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
> >>
> >>
> >
> >
>
>
Re: Changes in 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
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 <ac...@gmx.de> 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
>>
>>
>
>
Re: Changes in 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ac...@gmx.de> 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
>
>
Re: Changes in 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
Good point. It's not quite obvious what happens with the
root-element-class if a schema-assignment is used.
It is ignored completely.
I attached the root-element-class to the schema because a schema is
reusable and the users shouldn't need do define the class redundantly.
Additionally the schema rules are heavily depending on the container class.
The best solution might be to rename "root-element-class" to
"required-container-class" and add a optional "container-class" attribute
to the configuration point like you suggested.
1. if the configuration point specifies a container-class it has priority.
An instance of that class is created and passed to the schema.
The schema checks if that class is compatible with its
required-container-class.
2. if the configuration point doesn't specifiy a container-class then
the required-container-class of the schema is used.
3. if the schema is assigned afterwards then the original configuration
point
definition determines the container class. The schema
just checks if it is compatible like in case 1.
"required-container-class" even could be an interface. Case 2 would
throw an exception then.
Achim
Knut Wannheden schrieb:
> Nice!
>
> I've already got a question :-) Why is in the XML example the
> "root-element-class" on the <schema> element? I would have expected it
> on the <configuration> element as in the case of a <schema-assignment>
> the class of the container object will be given by the referenced
> configuration. Also I think the name "root-element-class" is not quite
> appropriate as it's not really tied to the root element. (Moreover the
> schema may define multiple root elements.)
>
> How about something like:
>
> <configuration-point id="ObjectProviders"
> container-interface="java.util.Map"
> container-class="java.util.HashMap">
>
> ?
>
> --knut
>
> On 11/7/06, Achim Hügen <ac...@gmx.de> 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
>>
>>
>
>
Re: Changes in 2.0 branch
Posted by Knut Wannheden <kn...@gmail.com>.
Nice!
I've already got a question :-) Why is in the XML example the
"root-element-class" on the <schema> element? I would have expected it
on the <configuration> element as in the case of a <schema-assignment>
the class of the container object will be given by the referenced
configuration. Also I think the name "root-element-class" is not quite
appropriate as it's not really tied to the root element. (Moreover the
schema may define multiple root elements.)
How about something like:
<configuration-point id="ObjectProviders"
container-interface="java.util.Map"
container-class="java.util.HashMap">
?
--knut
On 11/7/06, Achim Hügen <ac...@gmx.de> 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
>
>