commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Wannheden" <knut.wannhe...@paranor.ch>
Subject [HiveMind] more on BuilderFactory
Date Mon, 06 Oct 2003 08:58:57 GMT
Hi,

I had a few more ideas on how BuilderFactory can be improved. These
improvements mainly address the usage and extensibility of the service.

Right now the BuilderFactory is very flexible, but this comes at a cost: the
syntax is fairly complicated: there are four attributes and 17 different
nested elements...

I have been thinking if all the <set...> elements could be replaced with a
single <property> element. This element could then have a "translator" (or
"type") attribute; e.g.

    <property name="foo" value="22" translator="int"/>

Having a single element would of course mean that the translator feature of
the XML processing rules can't be used anymore, as the rules don't provide
conditional processing mechanisms. But the translation could also be
performed by the service itself, as the translator to be used is given. If
there were some kind of translator registry the BuilderFactory could then
also easily support new (even custom) translators, without requiring its
syntax to change.  E.g.

    <property name="foo" value="22.33" translator="float"/>

This idea could of course even be taken a step further. The "translator"
attribute could be skipped all together. Then the type of the corresponding
setter's attribute would tell BuilderFactory what translator to use.
Afterall, the type specified by the setter needs to be matched by the
translator. So specifying the type of the property in the hivemodule.xml
might be considered redundant by the user.

But what about <set-configuration> and <set-service>? If the setter
specifies a java.util.List parameter, then the corresponding configuration
could be looked up, and if an interface is required then a service could be
looked up. As a consequence setters with a List parameter could only accept
configurations, when used by HiveMind. If this is too restrictive, the
"translator" attribute could be optional, in which case also other
translators could be used for List setters.

Analogously, all constructor elements could be collapsed into a single
<constructor> element. But here the "translator" should maybe be required,
as finding the appropriate constructor could be hard otherwise.

What do you think about this idea? Would this work or have I missed
something important here? I could take a stab at implementing an optional
service implementing this strategy?

Would it make sense to add a HiveMind configuration for Translators?

Regards,

--knut




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message