hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Hügen <>
Subject Re: comments / questions on hivemind 2.0 branch
Date Mon, 06 Nov 2006 16:54:06 GMT

you are right, SchemaProcessor should be a service
and I would even make Schemas available via a SchemaManager
service too.
To make the parser based contribution possible as defined
in the contributeToFactoryConfig method in the example
we need a connection between configuration point, parser
and schema. Otherwise the contributor would always
have to specify which parser to use and I want to have a default.


Knut Wannheden schrieb:
> Achim,
> Instead of adding a new construct I think it would be cleaner to
> expose the parsers as  normal services. The contribution constructor
> would then be given access to the appropriate parser (or any other
> visible service) using the contextual construction parameter. I
> believe this would already work in your branch.
> So in the XML HiveMind module we'd expose the SchemaProcessor as a
> service which could be used by contribution constructors.
> This also turns out to be how it's solved in Tapestry 5. See 3rd
> example here: 
> What do you say?
> --knut
> On 11/6/06, Achim Hügen <> wrote:
>> Knut Wannheden schrieb:
>> >
>> > Maybe we could also drop the support for contributing to these
>> > configurations using XML. OK, I know this contradicts what I wrote
>> > about backwards compatibility in the other thread, but maybe that
>> > would be OK. I'd like to point out that Howard changed how the eager
>> > loading works in Tapestry 5 IOC. The ServicePointDef simply has a
>> > boolean getEagerLoad() method. How about that?
>> >
>> I think I've found a better solution (borrowed from
>> I will introduce a generic parser interface which is defined in the
>> framework
>> already and which is not xml specific. A configuration can have multiple
>> registered parsers.
>> A parser is responsible for the contribution of data to a configuration
>> which is defined in a textual format (especially file based data).
>> The SchemaProcessor then is one special parser which can process
>> inline data from a hivemodule.xml.
>> The idea is that the creator of a configuration point says 'ok, here is
>> a parser
>> which can read contributions from files' and the provider of a 
>> contribution
>> just says 'ok, then parse that file please'.
>> Pros:
>> + It solves our 'interface or no interface' dilemma. Since the parser
>> concept
>>   is available in the framework the hivemodule parser can be easily
>>   attached by the xml module afterwards.
>> + Configuration data can be defined in external files (xml, 
>> properties etc.)
>> Either the hivemind parsing is extended so that xml files can be parsed
>> that adhere to a hivemind schema or alternative parsers (e.g. Digester)
>> are used.
>> + Better integration of legacy data files
>> + Annotated modules can provide parsers easily (see annocon examples).
>> What do you think?
>> Achim

View raw message