From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-13 12:53:40
Hamish Mackenzie wrote:
>>Yes, I can see that, for the xml node types. But for that we don't even
>>need anything but a single 'node_proxy' class (with a 'type()' method
>>returning an enum).
>
>
> True.
>
> Though it might be useful in the next layer of the interface. If you end
> up with another proxy type that has lots of
>
> switch( raw_node_.some_node_property() )
> {
> ....
> }
>
> I use a very similar system in an HTML editor where the entity name is
> used to lookup the handler.
really the entire name ? Hmm. I'm thinking of the DOM spec(s), and
domain specific extensions. There typically new node types are
elements, i.e. they would (logically) all derive from dom::element.
(SVGElement, say).
Hmm, I'm not sure yet how to 'extend' dom::nodes towards these DOM
types. But it seems inheritance is not the right solution, especially
if we don't control the node's construction, i.e. we can't just plug
in a 'SVG node factory'.
Anyways, that's another layer...:-)
> Maybe we do need to allow the use of _private in higher level layers.
I don't think that's a good idea, in particular because it's to tightly
coupled to a particular implementation. We could allow a 'payload' for
nodes (possibly a template parameter), but we could as well do the
association between a node and its template in an external lookup
mechanism, which seems to be more clean and drag in the least overhead.
>>I start to like your node reference class quite a lot... :-)
>
>
> I am definitely leaning toward "node_reference" rather than "node_proxy"
> is that your preferred name too?
I was talking about your proxy approach as opposed to my node wrapper
classes that are constructed on the heap.
But yeah, concerning the naming I prefer reference over proxy.
>>yeah, a parser for asynchronous document creation may be interesting.
>>But I see that as a somewhat different beast. Simple (local,
>>synchronous) document creation from an xml file doesn't need to
>>go over a stateful parser object.
>
>
> Its not a high priority but it is nice that libxml2 supports it.
Agreed. So we could have both, stateless (synchronous) parsers creating
a document in a single call, and statefull asynchronous parsers that
can be bound to event loops or other 'signals'.
Regards,
Stefan