XML_CSSML, XML_XPath

I contacted Dan to know if he is still willing to maitain those packages.

Arnaud.

Sebastian Bergmann wrote:

For the record Dan cannot work on the packages he has a lead role. The
packages are orphaned.

I have marked dan as inactive on all his packages.

Arnaud.

Arnaud Limbourg wrote:

Helgi Þormar Þorbjörnsson fixed XML_CSSML in CVS. Could someone please
test his changes and roll a new release? Thanks!

I didn't tho fix the issue of wrong installation path, which is a
potential BC issue.

See: http://pear.php.net/bugs/bug.php?id=5574

QA needs to come to some conclusion what should be done.

- Helgi

The install path is correct (I updated the bug with this comment).

An issue though is related to PHP 5. I run 5.1.0-RC1 which throws a
fatal error because this package uses $this reassignement trick.

I can add a dep so the package cannot be installed under PHP5. People
installing the current release under PHP5 are in for trouble. It has
been downloaded > 21,000 times so far.

I don't see any other way out, except if we put a big warning telling
people need to update their scripts to use the factory method. That
would break BC though.

Arnaud.

To be clearer it boils down to two choices:

- add a dependency on PHP4, so it cannot be installed under PHP5
- add a warning telling people to update their script to use the factory
method and remove the $this reassignment trick

Bonjour,
Arnaud Limbourg wrote:
I still believe it's possible to correct this bug for any PHP
The trick could be done by adding a private property:
$_theObj = null;
if the constructor is called instead of the factory do:
$this->_theObj = $this->factory($in_driver, $in_CSSML,
$in_type, $in_params);
then correct all the methods in CSSML.php as:
function load()
{
if ($this->_theObj) {
return $this->_theObj->load();
}
if ($this->loaded) {
return PEAR::raiseError(null, XML_CSSML_ALREADY_EXISTS,
null, E_USER_WARNING, $this->CSSMLDoc, 'XML_CSSML_Error', true);
}
}
etc...
my 2cts
à+

Auto reply after an IRC discussion:
bertrand Gugger wrote:
Constructor should be (missed the &)
$this->_theObj = & $this->factory($in_driver, $in_CSSML, $in_type,
$in_params);
Also the properties to reassign in this case:
$this->loaded = &$this->_theObj->loaded;
... etc.
This methods and properties "reassignments" should be done for all
methods/properties inclusive what the drivers create.
On this way, 100% BC is guaranted for the standard package.
People customizing the drivers will have to use the "factory"

This adaptation only takes place for users of the constructor, will make
no difference (1 extra if () ) for the right "factory" users.

If the cops here agree, I can do it, test it and commit it so the
QA-team can release it.
à+

Yeah, just go ahead and do it, tho I think it's kinda of a extra work just
to support a obviously wrong way :P (assignment to this that is)

- Helgi

Bonjour,
Helgi Þormar wrote:
This package is just a nightmare.
I started the job, so naturally hooked on the package.xml where I
already fixed the example file name and put a right date so pear install
package.xml could work.
Actually the install path is now conform (XML/CSSML...) what breaks BC
as it was previously under XML_CSSML !
Dunno if the installer can build a link to correct this ...

Anyway, to the end, I could run the example, so now I'm ready to do the job.

Actually, helgi's fix for the $this assignment won't work: PHP5 issues
this fatal in the pre-scan phase, so make this assignment conditionnaly
does not change anything.
I will then (try to) apply the scheme I described

Wish me courage and luck :)
à+

The package.xml hasn't changed much in the past two years and the
install dir as
always been correct. The file gets installed as XML/CSSML.php which is
correct.
I wonder if we shouldn't go the "BIG WARNING with a dep on PHP4 and new
release
with a dep on PHP5" way, using $this is so wrong. Would it break many scripts
is the question.

Thoughts ?

Arnaud.

re
Arnaud Limbourg wrote:
Another question occurs which will perhaps solve the problem:
Can sound strange for many people, but I allways build my tests *before*
trying to repair such catasthrops.
So, I need a PHP5 with the domxml extension. It appears, domxml is no
more bundled in php but exists only as pecl extension. [1]
Now, and it was confirmed by chregu on IRC:
"This extension allows you to operate on an XML document with the DOM
API. It has been superseded by the DOM extension that ships with PHP 5.
Although it should be possible to use this old domxml extension with PHP
5, its use is highly discouraged, as there a very high potential for
conflicts with the new dom extension." [2]

So, half of the package is deprecated on PHP5 , the other half depending
on Sablotron.
What means, quite no other solution exists than:
1) releasing a PHP4 only fixbug, with no changes , or quite
2) creating a PHP5 (and perhaps PHP4 compat) new XML_CSSML2 if not
XML_CSSML5
This new package could make use of the bundled DOM [3] instead of domxml

Just, alternatively:
* it could perhaps be possible to use pear installer new features to
have a different installation depending on the php version
* the class could test for the existence of domxml or dom functions and
call the corresponding driver.

[1] http://fr.php.net/manual/en/ref.domxml.php
[2] http://pecl.php.net/package/domxml
[3] http://fr.php.net/manual/en/ref.dom.php

à+

Well I did say that I didn't test :-)

- Helgi

Halo,
Sebastian Bergmann wrote:
We come on dra(ma|s)tic solutions, here :
The onliest way is to restrict XML_CSSML to php4 and issue an XML_CSSML2
php5 compat, what means some delays. ( should go right thru pepr ? )
Sebastian, depending on the urgence, my solution could be temporarly,
unofficially distributed, in what kind of conf do you need it ?

For the existing XML_CSSML, I will change locally, test and commit in cvs:
* strict dependency on php4, needs to check the 4.4.0 branch too
* dynamically check the requested extension is present
* keep the $this assignment <sighs>
In order QA can release.

Please, comment ASAP as I don't want to lay here. But yes, no hastly
decision too.

I first realize the XML_Xpath is also concerned, will take a look too.
à+

Sounds like the only reasonable thing we can do now. (Apart from banning
such a nightmare of a package from PEAR.)

Thanks,
Sebastian

Bonjour,
Sebastian Bergmann wrote:
Done : http://marc.theaimsgroup.com/?l=pear-cvs&m=112912070532752&w=2
So far I could check , QA can now release.

re
Sebastian Bergmann wrote:
The problem is also solved for XML_XPath
http://marc.theaimsgroup.com/?l=pear-cvs&m=112912855212157&w=2
Here, it was just an assignment to $this in case of error, I repaired it
by adapting the isError() method and 2 other assignments to clear the
object, it's only clearing the properties now.

So QA can also release this package, here no php version limitation.
à+

For the record, both packages were released today.

Arnaud.

Got the following message from my fellow Gentoo developer:

When testing PEAR-XML_XPath, I found that it appears to depend on the
PEAR_Error class provided by PEAR-PEAR. However, the current version
of PEAR-PEAR appears to have deprecated PEAR_Error in favor of
PEAR_ErrorStack.

Also, in trying to test that PEAR-XML_XPath actually works, the
example script XML_XPath_example.php fails with the following;

Fatal error: Call to undefined function domxml_open_mem() in
/usr/share/php/XML/XPath.php on line 142

It looks like XML_XPath needs a "PHP 4 only" dependency, too, just like
XML_CSSML.

This is false, it has not been deprecated and probably never will be,
ErrorStack is simply a more sophisticated alternative to PEAR_Error.
Also "false", if one takes a look at www.php.net/domxml then you can see
it's a PECL ext that is said to "work" on PHP 5, so placing a domxml
dep is the way to go, then again, how well does it "work" under PHP 5 ?
Well maybe PHP 4 dep is the way to go if one wants no problem from this
thing, guess someone should write a decent PHP 5 support to XPath.

- Helgi

PHP 5 has out-of-the-box support for XPath in both DOM and SimpleXML.

ohh right, forgot about that, so yeah PHP 4 dep.

- Helgi

Version 1.2.3 has been released with the added dependency.

Arnaud.