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).
> 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.
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'.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk