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: comments / questions on hivemind 2.0 branch
Date Tue, 07 Nov 2006 13:44:53 GMT
There is one alternative I can think of. The SchemaRegistry service
could provided a hardcoded (using Java code) Schema for the "Schemas"
extension point. Then any <contribution> to the "Schemas"
configuration could be handled the same way as any other
<contribution>. But of course the contribution would then have to go
through the SchemaProcessor to create the Schema...

I think all the magic in the XML implementation of the API actually
warrants some complexity in its implementation. And I think we should
try hard to keep as much of this complexity out of the framework. Thus
I don't think either of these approaches would be that bad.

--knut

On 11/7/06, Achim Hügen <achim.huegen@gmx.de> wrote:
> It think it can be done this way.
> But now that you pointed out the consequences I'm no
> longer sure that this doesn't get too complex.
>
> Achim
>
>
> Am Tue, 07 Nov 2006 06:20:30 +0100 schrieb Knut Wannheden
> <knut.wannheden@gmail.com>:
>
> > James,
> >
> > Good point. I hadn't thought too hard about that but I think it should
> > be possible to bootstrap that. What we'd have to do is to:
> >
> > - Define the SchemaRegistry service using the Java or Java annotations
> > implementation of the API (as opposed to the XML implementation).
> > - Modify the existing XML DescriptorParser to handle <contribution>
> > elements to the "Schema" configuration the same way it handles
> > <schema> elements, which is to create the corresponding SchemaImpl
> > object and create a ContributionDef object for it. This
> > ContributionDef object would although use a ContributionConstructor
> > from the Java implementation of the API.
> >
> > This way the "Schema" configuration would not have a schema itself and
> > contributions to it would thus not require the "SchemaRegistry"
> > service in the ContributionConstructor. Also the "SchemaRegistry"
> > service can be setup without any schema processing if it's defined
> > using a Java or Java annotations module.
> >
> > Does this make sense?
> >
> > --knut
> >
> > On 11/6/06, James Carman <james@carmanconsulting.com> wrote:
> >> Aren't you getting into a chicken/egg scenario here?  You need to
> >> parse the XML to set up the services, but you need the services to
> >> parse the XML.  Sorry if I'm just jumping in the middle here with no
> >> context (I haven't been able to check out the new API yet,
> >> unfortunately), but this just sounded weird.
> >>
> >> On 11/6/06, Knut Wannheden <knut.wannheden@gmail.com> wrote:
> >> > Achim,
> >> >
> >> > I think I see what you're getting at. We could solve the whole problem
> >> > by defining the whole schema and parsing functionality in terms of
> >> > HiveMind services and configurations.
> >> >
> >> > The XML module could thus define a hivemind.xml.Schemas configuration
> >> > to which configuration and service points can contribute schemas.
> >> > Either implicitly by a <schema> element or explicitly with a normal
> >> > <contribution> element. I suppose a second configuration (e.g.
> >> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
> >> > of a schema to specific configuration or service points. Again, the
> >> > contributions to this would be explicit or implicit.
> >> >
> >> > Now a contribution constructor could access a
> >> > hivemind.xml.SchemaManager service (having the aforementioned
> >> > configurations injected) to retrieve the schema and / or parser (or
> >> > also a "pairing") for its configuration point.
> >> >
> >> > Does this correspond to what you were thinking?
> >> >
> >> > --knut
> >> >
> >> > On 11/6/06, Achim Hügen <achim.huegen@gmx.de> wrote:
> >> > > Knut,
> >> > >
> >> > > 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
> >> > > (http://annocon.sourceforge.net/manual/configurations.html)
> >> > > 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.
> >> > >
> >> > > Achim
> >> > >
> >> > >
> >> > > 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:
> >> > > > 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