On Mon, Mar 27, 2000 at 08:30:12PM -0700, Sean M. Burke wrote:
> At 06:41 PM 2000-03-27 +0200, Reinier Post wrote:
> >[...]
> >| * Does anyone write applications using HTML::Element that break
> >| encapsulation on HTML::Element objects? That is, by accessing object
> >| contents directly (like $node->{"id"}) instead of using accessors,
> >| like $node->attr("id")?
> >
> >I would rather not do that, but the interface requires
> >some extensions/modifications (as explained below).
> >[...]
>
> Okay, everyone, be aware that:
> * $node->attr('attrname', undef) now deletes the attribute
> * $node->all_attr() returns a list of the key/value pairs of all
> attributes. (Example return values: ('_tag', 'br', 'clear', 'all', 'id',
> '123').
Great news ...
> * $node->all_external_attr() returns a list of the key/value pairs of all
> "external" attributes (i.e., things corresponding to actual attributes in
> the SGML element, excluding things like _tag, _implicit, _content, etc.)
> Example return value: ('clear', 'all', 'id', 123).
Great!
> I suppose I could add something returning just the names of attributes, or
> of and external attributes. Would anyone find that useful?
Well, I'm not sure how to delete all attributes. What I do now is this:
my %daa = $node->all_attr;
map ($node->attr($_,undef), grep(/^[^_]/,keys %daa));
Thanks to your change, the grep will be superfluous, but I still can't
write to $node->all_attr(), so I'll still be iterating overits keys to
delete the attributes one by one.
> In any case, I hope that the new methods, above, mean that no-one ever has
> to break encapsulation on an HTML::Element object. Am I right, or are
> there cases I've not thought of?
I'll let you know when they show up :-)
> Aside from the problem of deleting attributes (now solved, I hope),
> modifying while traversing (fundamentally intractible, I think), and the
> frameset problem (I'm working on it), what problems are you running into?
None so far, but I've only been using HTML::TreeBuilder for a few days.
> If you want advice on how to have your traverse callback make notes on
> modifying a tree when the traversal is finished, do say so. There's
> several ways to do it.
I suppose I can annotate the nodes themselves with new attributes,
or use a hash to mark them. But my modified traversal() is serving
my needs for the moment.
> BTW, other things I'm quite likely to add in the next release: an option
> for controlling what elements as_HTML will return close-tags for. (I.e.,
> an ability to override the current set, which currently works to suppress
> such things as </p> and </li>.)
That would be useful. I'd like as_HTML to return close tags on a new
line, lined up with the open tags; as it stands it produces very long
lines.
> I've talked about this before, but I should really get around to having
> TreeBuilder and Element get their information about HTML from an external
> module, instead of each poking around at eachother's package variables.
Yes, this is in fact the reason I'm not subclassing from HTML::TreeBuilder.
I'm not convinced that changing the internal data structures is worthwhile;
performance tuners will use some form of output caching anyway, don't you
think?
Thanks for your response so far.
--
Reinier Post [EMAIL PROTECTED]
