The idea of simplexml is to return the nodes of *that particular node*,
not all of the subsequent nodes, therefore (as mentioned before), the
current behaviour is correct.
The current behaviour of to_xml_string() is however, wrong. It should
return the xml content from the current node as adam points out. The
current behaviour of to_xml_file() is appropriate, but inconsistent
(as adam's patch points out). to_xml_string() and to_xml_file() are
both rather confusing names as well.
My thoughts on this are as follows, some are directly related to the topic,
some are related to simplexml's original design and current functionality.
SimpleXML was originally designed to provide a direct mapping between a
XML document and a data structure, through access to the properties and
attributes and *only* the properties and attributes.
Much of the current code in SimpleXML is due to immaturities in either
Zend or the LibXML interface at the time I was writing SimpleXML. I wanted
to have cool things to show at conferences, plus other people wanted to see
what was possible with simplexml, so features started to creep in. xsearch()
and schema validation were the first added, then came other methods like
hasChildren() and getChildren() (when a simple xpath query /child::node() can
tell you this)
Most of simplexml's methods are either redundant, or redundant based
upon redundancy (hasChildren(), getChildren(), attributes(), count()).
Each of these methods are actually a very simple, very optimized xpath
expression.
I know its late in the process, but its also the last chance for an API
change, or rather adjustment, the change was always meant to happen, I
just got a bit too busy to do it. So here are my thoughts on an API:
1) Remove all methods from simplexml. They were never supposed to be
permanent parts of the API.
2) Add three new functions:
simplexml_register_ns(simplexml_element $e, string name, string value)
simplexml_save_file(simplexml_element $e, string filename)
simplexml_save_string(simplexml_element $e, string &$data)
The last two functions will work as Adam mentions, saving from the current
node. The copy of the data can be omitted, since libxml2 should be
using our memory management functions.
3) For the next version of PHP, PHP5.1 add a new xpath extension which
provides a generic query interface to XML objects. This would be
something like:
if (xpath_query('/child::node()', $node, $results)) {
}
As xpath is very much akin to regular expressions for XML. This is a
more elegant solution than the current DOM api for XML which would
require a casting into a dom object, then a domxpath object, then a
simplexml object. (*)
I realize this is a rather drastic change so late in the game.
But this was the original intent of the extension, and indeed is more consistent
than the current solution. I also think that the current direction with
these helper methods is wrong. They don't help, they just muddy the
waters up.
As a further note. SimpleXML is not currently ready for production
usage, I've been going through it over the past couple of days, and it
needs some work (especially since some bugs in Zend currently make
things impossible). I'm loth to do a deep grotting of the extension
(even though its easier now that we have a test suite), but quite a bit can be won
in terms of consistency and stability (code path) - I think this should
be a part of that work, and I would be willing to make the necessary
changes.
Anyhow, these are my thoughts on the matter.
-Sterling
(*) The DOM api could be left for PHP5.0, but shouldn't be the only
option. The xpath extension would actually be quite trivial, and could be
done quickly. Most of the code is already in DOM and SimpleXML, it would just
be moving it to a separate extension.
> The patch you propose is exactly the type of functionality that I was
> hoping to find.
>
> Thank you,
> Blake Schwendiman
>
> -----Original Message-----
> From: Adam Maccabee Trachtenberg [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 11, 2004 11:54 PM
> To: Andi Gutmans
> Cc: Marcus Boerger; Blake Schwendiman; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] SimpleXML and Default Cast To String
>
> On Thu, 8 Jan 2004, Andi Gutmans wrote:
>
> > At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
> > > > So i'd say let us add a method for returning the complete content.
> Adam
> > > > could you do that?
> > >
> > >That wouldn't be too difficult (although I am busy for the next day
> or
> > >two). However, as much as I loathe toggles, I'm wondering if it
> > >wouldn't be better to make this an object-wide setting. My thought
> are
> > >that on an object-by-object basis, you either always want tags or
> > >never want them.
>
> [snip]
>
> > I'd keep things the way they are today.
>
> I've spent a little time looking at the code and I realize I
> misunderstood what was going on. Right now, given this XML:
>
> <foo>
> A<b>B</b>C
> </foo>
>
> Doing a "print $xml;" prints "AC". I think we should be printing
> "ABC". Doesn't this make more sense? I don't mind eliminating the
> tags, but we also kill the text node children and that doesn't seem
> what I'd expect.
>
> The second issue is how do we allow people to get the string with
> tags, or "A<b>B</b>C"? (This is what I thought we were talking about.)
> For that, I think the best method is to modify to_xml_string() and
> to_xml_file().
>
> Right now, we serialize the entire document regardless where in the
> document these methods are called. Instead, I say these methods should
> just serialize from the current location on down. So, this:
>
> print $xml->b->to_xml_string();
>
> Prints this:
>
> <b>B</b>
>
> I've whipped up a patch that does this:
> http://www.trachtenberg.com/patches/simplexml_toxmlstring_patch.txt
>
> Comments?
>
> -adam
>
> --
> [EMAIL PROTECTED]
> author of o'reilly's php cookbook
> avoid the holiday rush, buy your copy today!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
