HTML::Element accessing "internal attributes" the proper way

cormanaz has asked for the wisdom of the Perl Monks concerning the following question:

Greetings fellow seminarians. My sympathies to those of you who, like me, are programming on Christmas Eve.

I am using HTML::TreeBuilder to parse HTML for the purposes of extracting information on some web pages, using HTML::Element to do this. When I do something like my $d = $tree->look_down('class','date'); the hash I get back has a {_content} array with the values I want.

The docs describe keys beginning with underscore as "internal attributes," which I suppose means I'm not supposed to access the directly, but I can and do. For example my $date = $d->{_content}->[1]

But I'm wondering if there is a more proper construction for this. For example, in LWP::UserAgent you can get $response->status_line which I think accesses an internal attribute. In the date example my $date = $d->content[1] doesn't work. I've searched around and have not been able to find an answer.

Comment on HTML::Element accessing "internal attributes" the proper way Select or Download Code

Replies are listed 'Best First'.
Re: HTML::Element accessing "internal attributes" the proper way by jcb (Parson) on Dec 25, 2020 at 03:27 UTC
A quick look at the HTML::Element documentation suggests using the `content_list` method, as in `my $date = ($d->content_list)[1]`. If there was no element `1` in the content list (as when the element is empty), this will set `$date` to `undef` and might produce a warning. Alternately, your use of `content` was very close: the `content` method returns an arrayref or `undef`, so you want `my $date = $d->content->[1]` but note that that will crash if the element has no content, so you might want to use eval: `my $date = eval { $d->content->[1] }` which will set `$date` to `undef` (and set `$@` to an error about attempting to dereference something that was not a reference) if the element has no content. (All code obviously untested.)	[reply] [d/l] [select]
Re^2: HTML::Element accessing "internal attributes" the proper way by LanX (Saint) on Dec 25, 2020 at 06:55 UTC
> his will set $date to undef and might produce a warning. this would surprise me `DB<71> use warnings; $a=(1..2)[9] DB<72>` [download] > so you might want to use eval: `my $date = eval { $d->content->[1] }` Thats why the use is of `->content` is discouraged and `->content_array_ref` is offered `$content_array_ref = $h->content_array_ref(); # never undef` [download] "This is like content (with all its caveats and deprecations) except that it is guaranteed to return an array reference." > (All code obviously untested.) dito! :) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]
Re^3: HTML::Element accessing "internal attributes" the proper way by jcb (Parson) on Dec 26, 2020 at 01:30 UTC
I said "might" because I was not sure off the top of my head whether reading off the end of a list produces a warning in Perl or not. As the documentation says, `content_array_ref` is just as deprecated as `content`, with `content_list` being the preferred interface for new code.	[reply] [d/l] [select]
Re^4: HTML::Element accessing "internal attributes" the proper way (updated) by LanX (Saint) on Dec 26, 2020 at 02:54 UTC
Re: HTML::Element accessing "internal attributes" the proper way by Anonymous Monk on Dec 25, 2020 at 01:44 UTC
Docs? `content_list content content_array_ref content_refs_list` [download] https://metacpan.org/pod/HTML::Element#content_refs_list look_down is nice, but Re^3: Truncating an HTML node using XPaths in HTML::TreeBuilder::XPath ( pindex splice_content content_array_ref ) Use htmltreexpather.pl to help you write more appropriate xpaths See limbo WIP future Re: Issues using HTML::TreeBuilder::XPath and the HTML5 <section> tag ( ignore_unknown => 0 ), HTML::TreeBuilder::LibXML	[reply] [d/l]
Re^2: HTML::Element accessing "internal attributes" the proper way by cormanaz (Deacon) on Dec 25, 2020 at 16:34 UTC
Wow not sure how I missed that in the docs. Thanks for the pointers.	[reply]