Re: Re: Re: XML::Twig error reporting

I have to think about it. The problem I see is that, although this is a usefull and clever trick, it would probably be used quite infrequently, while slowing down every print or sprint... Though as I would limit it to attributes starting with #, it would only cost one substr() per attribute. I think silently removing all illegal attributes is too dangerous for the user, and checking them might get me into Unicode trouble. Now what about elements names starting with #

BTW if I go this route I might as well add an option to generate the line/column attributes ;--)

Comment on Re: Re: Re: XML::Twig error reporting

Replies are listed 'Best First'.
Re: Re: Re: Re: XML::Twig error reporting by John M. Dlugosz (Monsignor) on Nov 14, 2001 at 05:27 UTC
I ended up using a hash member after all: `sub store_position { my( $t, $elt)= @_; my $line = $t->{twig_parser}->current_line; # $t->{twig_parser} +is the expat object my $column = $t->{twig_parser}->current_column; $elt->{custom_atts}{position}= [$line, $column]; # crude but works }` [download] The compelling reason was because I can't assume that the attr mechanism would handle anything other than strings, while a custom-data ability would be defined to handle any Perl object. I still agree that you should simply document the hash key. But, that also exposes that it =is= a hash, so having get/set custom data members would be better. I mentioned before that an advantage to using att() is that the normal selection mechanisms work. Here are two more: I can have an explicit line/col in an XML document, much as the #line directive is used in C/C++ -- it can reference the original document's source location. Second, when I add or transform elements (e.g. with split) the new ones don't have this row/col information. An att() could automatically inherit the value from the parent. A documented get_custom_data(KEY) function could also be programmed to inherit. —John	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: Re: Re: XML::Twig error reporting
by John M. Dlugosz (Monsignor) on Nov 14, 2001 at 05:27 UTC

sub store_position
 {
 my( $t, $elt)= @_;
 my $line   = $t->{twig_parser}->current_line;    # $t->{twig_parser} 
+is the expat object
 my $column = $t->{twig_parser}->current_column;
 $elt->{custom_atts}{position}= [$line, $column];   # crude but works
 }
[download]

I still agree that you should simply document the hash key. But, that also exposes that it =is= a hash, so having get/set custom data members would be better.

I mentioned before that an advantage to using att() is that the normal selection mechanisms work. Here are two more: I can have an explicit line/col in an XML document, much as the #line directive is used in C/C++ -- it can reference the original document's source location. Second, when I add or transform elements (e.g. with split) the new ones don't have this row/col information. An att() could automatically inherit the value from the parent. A documented get_custom_data(KEY) function could also be programmed to inherit.

—John

[reply]
[d/l]