On Wed, 12 Apr 2006 17:47:19 +0100, zdennis <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ross Bamford wrote:
>> Hi,
>>
>> I've today committed changesets including Mark Van Holstyn's patches, an
>> additional patch I received from Tim Yamin, and a few small fixups and
>> extra tests. These fix bugs in XML::Node#content, and add several
>> convenience methods to Node and Node::Set as previously discussed, as
>> well
>> as defining node equality based on the XML representation.
>
> does this mean? node1 === node2
At the moment, it means that
"<node1/>" (.eql?|==|===) "<node1/>" => true
"<node1/>" (.eql?|==|===) "<node2/>" => false
"<node1/>" (.eql?|==|===) "<node1 a='b'/>" => false
I'm open to suggestions as to how it could be put to better use (esp with
respect to ===).
>
>>
>> I am now considering implementing callback procs for the SAX parser, and
>> would appreciate any ideas anyone might have. Currently I'm looking at
>> two
>> choices:
>>
>> 1) Having methods for each callback supported by libxml, which
>> work like set_trace_func:
>>
>> saxparser.set_begin_document(lambda { |...| })
>> saxparser.set_begin_element(lambda { |...| })
>> # ...
>
> I seem to be a fan of the on_* naming convention for callbacks, since
> the terminology "on" itself seems to show that somethng will
> happen. And I like just passing blocks.
>
> saxparser.on_begin_document { |doc| ... }
>
> # callback for all elements
> saxparser.on_begin_element { |node| ... }
>
> # callback for only the elements which are "mynode"s
> saxparser.on_begin_element( "mynode" ) { |mynode| ... }
>
The only reason I tend to prefer the lambda syntax here is because it
makes it easier to remove handlers (by passing nil, rather than just
having a no-block call).
I like the 'on' naming convention, maybe I'll use that. Thanks :)
>
>>
>> 2) Introducing a new class (maybe XML::SaxParser::Callbacks?)
>> that provides the above API, and then having e.g.:
>>
Yeah, I agree with you on this one - Further consideration convinced me
that it was a pointless abstraction however the procs themselves are
handled.
Cheers,
--
Ross Bamford - [EMAIL PROTECTED]
_______________________________________________
libxml-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/libxml-devel
