> > 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.
>
Ahh, i missed validation. See notes below.
> > 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)
>
dom has a function to do this.
> >
> > 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.
>
Yeah, I had it the other way for consistency but would be willing to
yield to popular opinion. ;)
> > 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.
Well, that's certainly an option. Whilst I prefer to have standard
api's for this across PHP, I'm not terribly adamant about this
particular issue. The main idea would be to have a standard schema
interface and a standard xpath interface that would work perfectly with
both DOM and SimpleXML objects, in fact the two would be interchangeable
because they are both libxml objects underneath. I think that would be
sexy, but I'm willing to give it up.
The problem with simplexml_xpath_query returning an array is that how do
you signify failure and an empty set. In order for you to have code
that uses foreach() it would need to return an empty set on failure in
order to avoid warnings. The reason that there is an extra argument (as
with PCRE) is for the failure condition.
>
> > 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. :)
>
:)
It doesn't have too many leaks, its just terribly inconsistent
underneath. It also has some crashes when you reach edge cases.
Partially due to Zend, partially due to some sloppy coding.
> 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'll look at this today.
>
> 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.
I'm happy for any help. But I want to make sure to open this up to
disagreement before we go ahead and start fixing things.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
