Knut Wannheden schrieb:
Achim,
to be represented by a xml specific implementation of
ConfigurationPointDefinition
which is not available in the framework when they get constructed.
Natures (or better decorators) solve this problem.
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
