Melanie Rouette <[EMAIL PROTECTED]> wrote:
>
> I need to create xml DOM trees from scratch save them as xml files
> so that I can reload them & make modifications to the elements'
> values as well as adding new elements or attributes. Right now I'm
> using the XML::LibXML::Document & XML::LibXML::Element classes.
>
> And I have a bunch of questions...
>
> 1- I would to give an XPath expression as a parameter to a method
> and get as a result a pointer to the position in the DOM tree to
> either add a nee element/attribute or modify an existing one. How
> do I do that?
In general, it's quite difficult to do this with XPath, since
the expression can refer to multiple nodes.
And consider:
my $xpath = "//foo/@bar";
$node->selectSingleNode($xpath) = $value;
If there are multiple <foo/> elements, fine, you take the first
one, but if there aren't any, where on earth would you create it?
That said, it could work in simple cases and I've definitely
seen a library that tries to do XPath-autovivification, but
can't remember which one (or even if it was Perl). :/
Pretty sure libxml doesn't try it.
> 2- Is there a way to have "C++ like friend class" in perl?
The concept doesn't apply.
[this could have been a seperate post by the way]
In the most common case, a Perl object is a blessed hash reference.
package Foo;
sub new {
my $class = shift;
my $self = { name => "Foo", kids => [] };
bless $self, $class;
}
And from here on out, *anybody* can go in and access the hash
directly (not to say that they should, but they can), so there's
no need to explicitly grant access to "friendly" classes/methods.
Meaning you can do this anywhere:
my $foo = Foo->new;
$foo->{name} = "Bar";
OTOH, the "standard" hack (but it's much, much, much less
common than the hashref) for hiding instance data goes something
like:
package Bar;
my %members = (name=>1, kids=>1);
sub new {
my $class = shift;
my %data = ( name => "Bar", kids => [] );
my $sub = sub {
my $m = shift;
return unless $members{$m};
$data{$m} = $_[0] if @_;
$data{$m};
};
bless $sub, $class;
}
sub name { my $sub = shift; $sub->("name", @_) }
sub kids { my $sub = shift; $sub->("kids", @_) }
Now the data is hidden from everybody.
Only the closure ($sub) can see %data, so the *only* way to access
it is by calling the closure, the way name() and kids() do.
Which means: in this case there's nothing you can do to make access
easier for a friendly class/method. Even Bar itself has to get at
the data indirectly...
And as a third scenario (which might be the one you're interested
in after all) there are XS modules where the instance data is off
in C-land somewhere and only the wrapped C library knows how to
access it.
There's nothing preventing you from writing the "friend" class in
XS, though, or with unpack() :). But Perl can't help you.
> 3- Do XML::LibXML::Document & XML::LibXML::Element class methods
> understand Xpath expressions or do I absolutly have to use
> XML::XPath::Element?
LibXML can do it. find{,nodes,value}
> 4- Is there a class that represent a DOM tree in XML::XPath package
Yes.
Don't remember the name, but the answer must be in the manpage... :)
IIRC, it uses a custom DOM-like structure which is not fast (a lot
of niggly low-level stuff written in Perl) and not quite compatible
with any of the other DOM-style modules.
> and is there one which would be a parser like the XML::LibXML
> module ...
It's built on top of expat (XML::Parser).
> Does it provide the same functionalitites XML::LibXML::Document
> does?
Not nearly. But it's easy to install and never segfaults, which
was a significant advantage at one point. :)
Anyway libxml is the best, and if you've got XML::LibXML (or GDOME)
available, use it.
--
Steve
perldoc -qa.j | perl -lpe '($_)=m("(.*)")'
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]