[PEAK] XML Configuration and Serialization
ueck at net-labs.de
Tue Jun 1 10:40:53 EDT 2004
> Unlike ZConfig, however, we won't use a separate schema. Instead, we'll
> use PEAK's existing configuration system. I figure it'll look something
> like this:
> [XML Elements for http://peak.telecommunity.com/example_namespace]
> foo = "somepackage.someclass"
> bar = "somepackage.anotherclass"
> * = "somepackage.function_that_raises_an_error"
> So, this simple schema allows 'foo' and 'bar' elements at its top
> level. As with DOMlets, configuration lookup takes place relative to the
> containing XML element, so this means that 'foo' and 'bar' could define
> their own "XML Elements for <namespace>" that defined other elements
> available inside a foo or bar element.
looks good, i have written some DataManager that use the
same idea (map element-name -> <metamodel>.<class/feature-name>
directly. this would reduce the needed work for the parser to
just writing the elements that handle the data + config - nice.
is the result a tree of model.Elements or binding.Components ?
if you plan to process streams, there need to exist serialization and
deserialization (that would mean, component/element-trees could be
saved to a string/file as well) or do you plan do it like this:
xmlin -> IDOMletNode(object-from-xml).render -> xmlout ?
do you plan to be able to process arbitary xml-data/streams,
or only ones that match a curtain scheme ?
to implement context-dependent behaviour (e.g. handle
element/attribute-nodes differently because they have a
different meaning in this context),
i provide configuration within the parent component
for the namespaces used by these nodes that alter the "handler"
and therefore what happens .. right?
> These changes may have some impact on custom DOMlets, although I'll try to
> keep it to a minimum by ensuring that created DOMlets end up with the same
> attributes as before, even though different classes will be doing the work
> of setting them up.
/me has only worked out a few domlets for prototyping .. i don't care
rewriting there in favour to e.g. the generator-based interface we
More information about the PEAK