#38595 [Com]: XSLTProcessor::registerPHPFunctions() should be able to register callbacks
ID: 38595
Comment by: php at xmlnode dot com
Reported By: goliath dot mailinglist at gmx dot de
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.1.5
New Comment:
I'm not sure how important this really is. I too was disappointed at
the lack of flexibility with registerPHPFunctions, but it was hard to
be too upset about it because for us, the decision to use XSL as a
template is an acknowledgment of standards and registerPHPFunctions is
not standard...
What we've done, if the value can't be passed as a parameter using
XSLTProcessor::setParameter() is created a class with a bunch of
static methods which are then called using something like this:
php:function('XSL::',0)
If objects need to be instantiated, that work is done inside of those
respective methods -- not throughout the XSL. The approach here has
the added benefit of being able to periodically scrutinize what others
on the team are wanting access to within the XSL and make adjustments
for security, performance, etc.
YMMV
Previous Comments:
[2006-08-25 17:09:21] goliath dot mailinglist at gmx dot de
Description:
XSLTProcessor::registerPHPFunctions() has very limited use. It is only
possible to register static callable functions.
Some nicer API would be:
$xslt = new XSLTProcessor()
$xslt->registerPHPFunctions(array(
'func1' => 'functionblah',
'func2' => array('class', 'method'),
'func3' => array($obj, 'method') // this would be the real advantage
));
Or even better:
$xslt->registerPHPFunction('func1', 'functionblah');
$xslt->registerPHPFunction('func2', array('class', 'method'));
$xslt->registerPHPFunction('func3', array($obj, 'method'));
$xslt->removePHPFunction('func1');
This would be similar to the set/get/removeParameter-API
btw.: Your CAPCHA only works with cookies enabled, that really sucks.
Reproduce code:
---
None, not possible
Expected result:
Be able to have instance-methods as callbacks for the XSLTProcessor.
(Note: Not global accessibly objects)
Actual result:
--
Not possible
--
Edit this bug report at http://bugs.php.net/?id=38595&edit=1
#36917 [NEW]: simplexml_load_file throws multiple errors making track_errors ineffective
From: php at xmlnode dot com
Operating system: Debian
PHP version: 5.1.2
PHP Bug Type: SimpleXML related
Bug description: simplexml_load_file throws multiple errors making
track_errors ineffective
Description:
when simplexml_load_file fails (because the target xml file is empty for
example) there are multiple, basically useless, errors reported that makes
track_errors and $php_errormsg ineffective
My workaround has been to load the file using dom and grab it's relevant
error message then use interop to switch to simple if everything is ok...
definitely sub-optimal.
Reproduce code:
---
Expected result:
either:
"empty.xml:1: parser error : Document is empty"
or:
"empty.xml:1: parser error : Start tag expected, '<' not found"
Actual result:
--
"^"
If you enable display_errors you'll see that there are 3 warnings for each
'error' ("Document is empty" and "Start tag expected") There's the
relevant error, then an empty error message and then the last one where
the message is just "^" and because that's the last one, that's the one
stored in $php_errormsg.
--
Edit bug report at http://bugs.php.net/?id=36917&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36917&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36917&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36917&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36917&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36917&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36917&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36917&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36917&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36917&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36917&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36917&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36917&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36917&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36917&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36917&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36917&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36917&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36917&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36917&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36917&r=mysqlcfg
#37042 [NEW]: libxml_get_last_error always returns error after importStylesheet
From: php at xmlnode dot com
Operating system: Solaris, Debian, Windows
PHP version: 5.1.2
PHP Bug Type: XSLT related
Bug description: libxml_get_last_error always returns error after
importStylesheet
Description:
It seems that libxml_get_last_error always has an error after importing a
perfectly valid, well-formed, xsl stylesheet.
This makes it difficult to determine if there is really a problem with the
stylesheet versus 'noise'. :(
Reproduce code:
---
load('foo.xsl');
$y->importStyleSheet($x);
var_dump(libxml_get_last_error());
// not needed to show the problem, but if uncommented works
// $x->loadxml('');
// echo $y->transformToXML($x);
?>
// the stylesheet which opens without error in other parsers
http://www.w3.org/1999/XSL/Transform";>
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" />
hi
Expected result:
No errors. In fact, if you comment the vardump and uncomment the last two
lines of the reproducable code above, it will transform the document as
expected, but there's still an error in libxml. I recognize that libxml
is outside of your immediate jurisdiction, but was hoping you could alter
libxml_get_last_error to be smarter or something... not sure what I'm
hoping for exactly.
Actual result:
--
object(LibXMLError)#3 (6) {
["level"]=> int(3)
["code"]=> int(77)
["column"]=> int(1)
["message"]=> string(47) "Premature end of data in tag stylesheet line
2 "
["file"]=> string(37) "file:///c%3A/xampplite/htdocs/foo.xsl"
["line"]=> int(11)
}
--
Edit bug report at http://bugs.php.net/?id=37042&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37042&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37042&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37042&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37042&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37042&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37042&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37042&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37042&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37042&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37042&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37042&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37042&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37042&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37042&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37042&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37042&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37042&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37042&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37042&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37042&r=mysqlcfg
#37042 [Bgs]: libxml_get_last_error always returns error after importStylesheet
ID: 37042
User updated by: php at xmlnode dot com
Reported By: php at xmlnode dot com
Status: Bogus
Bug Type: XSLT related
Operating System: Solaris, Debian, Windows
PHP Version: 5.1.2
New Comment:
sorry, libxml version 2.6.220. I'll drop this off at xmlsoft. For my
workaround I'm checking sizeof(libxml_get_errors) which is 0 even when
libxml_get_last_error has it's 'error'.
Thanks!
Previous Comments:
[2006-04-11 17:58:30] [EMAIL PROTECTED]
which libxml2/libxslt versions are you using.
It works for me and prints
bool(false)
And you're right, it's nothing we can do about it. File a bug
at xmlsoft.org, if you can reproduce the error with the latest
libraries
[2006-04-11 17:58:29] [EMAIL PROTECTED]
which libxml2/libxslt versions are you using.
It works for me and prints
bool(false)
And you're right, it's nothing we can do about it. File a bug
at xmlsoft.org, if you can reproduce the error with the latest
libraries
--------------------
[2006-04-11 17:40:14] php at xmlnode dot com
Description:
It seems that libxml_get_last_error always has an error after importing
a perfectly valid, well-formed, xsl stylesheet.
This makes it difficult to determine if there is really a problem with
the stylesheet versus 'noise'. :(
Reproduce code:
---
load('foo.xsl');
$y->importStyleSheet($x);
var_dump(libxml_get_last_error());
// not needed to show the problem, but if uncommented works
// $x->loadxml('');
// echo $y->transformToXML($x);
?>
// the stylesheet which opens without error in other parsers
http://www.w3.org/1999/XSL/Transform";>
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" />
hi
Expected result:
No errors. In fact, if you comment the vardump and uncomment the last
two lines of the reproducable code above, it will transform the
document as expected, but there's still an error in libxml. I
recognize that libxml is outside of your immediate jurisdiction, but
was hoping you could alter libxml_get_last_error to be smarter or
something... not sure what I'm hoping for exactly.
Actual result:
--
object(LibXMLError)#3 (6) {
["level"]=> int(3)
["code"]=> int(77)
["column"]=> int(1)
["message"]=> string(47) "Premature end of data in tag stylesheet
line 2 "
["file"]=> string(37) "file:///c%3A/xampplite/htdocs/foo.xsl"
["line"]=> int(11)
}
--
Edit this bug report at http://bugs.php.net/?id=37042&edit=1
