hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Wannheden" <knut.wannhe...@gmail.com>
Subject Re: Re: comments / questions on hivemind 2.0 branch
Date Mon, 06 Nov 2006 10:59:09 GMT
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: http://tapestry.apache.org/tapestry5/ioc/configuration.html.

What do you say?

--knut

On 11/6/06, Achim Hügen <achim.huegen@gmx.de> 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
> http://annocon.sourceforge.net/manual/configurations.html)
> 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
>
>
>
>
>
>
>

Mime
View raw message