Hello Adam,
Monday, January 12, 2004, 10:21:23 PM, you wrote:
> 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.
Id like to see a new object type for SimpleXML here instead of the array
aproach (say SimpleXML_List). This because the array approach doesn't solve
everything. But we can postpone that until after 5.0 is out because at least
for the moment i can live with arrays.
> 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.
We are not consistent! Not in any way. DOM uses studlyCaps and SimpleXML
uses underscores for its method names. Speaking of consistency we should
probably discuss whether we want to change all methods of SimpleXML to
studlyCaps (we cannot hcnage the DOM method names). Until RC1 i guess we
can do such changes if we all agree and see it to be important.
> 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
--
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
