On Fri, 2003-06-13 at 16:11, Stefan Seefeld wrote:
> well, it looks like a mix of things. What you are doing, essentially,
> is wrapping a polymorphic 'do_something' method around a non-C++
> type system, i.e. the real method invocation is done with a 'type()'
> discriminator.
Yes.
> 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. Because the lookup can be slow I cache the
result in the node itself. We might have to expose _private if we
wanted to do that :-(.
Maybe we do need to allow the use of _private in higher level layers.
If so how about something like this?...
template< typename Value_Type, ... >
class document;
template< typename Value_Type, ... >
class node_reference
{
public:
void value( Value_Type * value )
{
node_->_private = value;
}
Value_Type * value() const
{
return static_cast< Value_Type * >( node_->_private );
}
};
Or some such???
> I think it is a good thing not to own them, but the semantics should
> be clear.
>
> >>yes, and you could even make that an 'element_proxy' as you know that
> >>parent nodes are always elements. However, with a flat set of (libxml2)
> >>nodes that wouldn't work any more, so runtime polymorphism would be
> >>lost. Well, may be there is no need for it either. I have to think over
> >>that...
> >
> >
> > True and that would fit in nicely with the code I outlined above
> >
> > node.first_child().do_something( 0 );
> >
> > Would go through the polymorphic lookup and
> >
> > node.parent().do_something( 0 );
> >
> > Would call the same code but without the lookup overhead.
>
> indeed, though, on further thinking, nodes themselfs don't do anything,
> so we could as well keep this polymorphism outside the node class, and
> let nodes only provide their type as an enum.
>
> 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?
> >>>parse_stream would indeed be even better. As I recall there are
> >>>functions in libxml2 that allow you to write to the parser as well.
> >>
> >>erm, that's even more confusing, I think. A parser should remain
> >>just a parser, i.e. something that extracts tokens from an input stream.
> >
> >
> > It is still just a parser (but works as a state machine). Check out
> > xmlCreatePushParserCtxt and xmlParseChunk.
> >
> > Say you need to receive lots of xml files over the internet and parse
> > them all at once. You could use a thread per connection and have the
> > parsers read from the stream but that would require lots of threads.
>
> Are you suggesting that all the different xml files should be merged
> into a single dom document ?
No many separate documents each needing there own parser and thread.
> > With the "push" interface you can use async io to read from the sockets
> > and then write the data to the parsers as you get it. Because the state
> > of the parse is not stored on the stack you do not need a separate
> > thread for each parser.
>
> 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.
--
Hamish Mackenzie <[EMAIL PROTECTED]>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
