On Mon, 12 Jan 2004, Sterling Hughes wrote:
[snip]
> > simplexml_save_dom(simplexml_element $e, domDocument $dom)
> >
>
> dom has a function to do this.
I guess it doesn't make too much difference whether DOM imports a
SimpleXML object or SimpleXML exports a DOM object to me.
[snip]
> > > 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.
Well, domXPath::query() now returns a DOM-style nodeList object
instead of an array. This is consistent with DOM's
getElementsByTagName() method, but different from SimpleXML's
array-based approach.
One solution could be to vary the return types based upon the input
type (arrays for SimpleXML, nodeLists for DOM), but that doesn't seem
like a wise decision to me. I'm open to other options.
In theory, I like the idea of a unified set of XML helper extensions,
but DOM's so big and ugly that I don't know if it plays well with
others in the sandbox.
Rob will probably have an opinion here, I'm sure.
> 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 know, I'm just a sloppy coder...
[snip]
> > 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.
Thanks. Like I said, it's a bit of a pain, but nothing killer.
> > 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.
Ditto.
-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
