On Mon, 12 Jan 2004, Sterling Hughes wrote:
> 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.
I yield to popular opinion and voice of the original
author. :)
> 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.
I've also never liked those names either, but it seemed bad form to
request changes in the API.
> 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.
I am in strong agreement here.
> 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.
The only SimpleXML methods (besides the ones for getting data in and
out of the object) I care about are xquery and validation. I've never
used (or really even known about) the other ones and don't see a need
for them.
> 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)
simplexml_save_dom(simplexml_element $e, domDocument $dom)
>
> 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.
I prefer it when functions that create strings and objects return
them, so I vote for:
string simplexml_save_string(simplexml_element $e)
I want to be able to do:
if ($data = simplexml_save_string($e)) {
print $data;
}
The preg() functions have an API like yours and I hate it. They always
require an extra step to extract the data from the $results array.
> 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. (*)
If you're going to blow things up, I would much prefer that you
somehow manage to get this into PHP 5.0. Right now, AFAIK, xsearch()
is the only way to do any XML Namespace querying and casting things
through that chain of objects causes me to barf more than even XML
Namespaces. :)
And, as you say below, this code already exists in xsearch(), it's
just a matter of figuring out where to put it. Why not just do:
array simplexml_xpath_query(simplexml_element $e, string $xpath)
This allows for:
foreach(simplexml_xpath_query($node, '//foo') as $foo) {
print $foo;
}
DOM is explicitly an OO API. You seem to want SimpleXML to be
procedural. (I must admit here that I actually like the SimpleXML OO
API.)
Therefore, I think it makes sense for domXPath to continue to be an OO
solution for DOM and just build in an procedural XPath function into
the SimpleXML extension.
> 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.
I'm about to put it into production use, so we'll see about that. I
will be using it as a CGI, however, so leaks aren't a problem. :)
We've also never discussed the infamous scalar versus array issue you
promised me you'd fix at ApacheCon:
if (is_array($e->foo)) {
$foo = join(',', $e->foo);
} else {
$foo = $e->foo;
}
I think this opens a whole 'nother can of worms, but if you're looking
to clean things up, now's the right time. :) I caused quite a ruckus
with my request for autocasting to a string. I'm interested in seeing
how this one gets resolved. Seriously, the code above is a bit of a
kludge, but totally workable.
I would be willing to help out here as I've spent a bunch of time
hanging about the libxml2 API already while trying to fix PHP 5 XML
issues.
-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
