Gnumeric Better Namespace Handling #2022
Conversation
There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment PHPOffice#860 (comment) in issue PHPOffice#860 by @IMSoP has triggered an idea about how to proceed. Although the issues exclusively concern Xlsx format, I am starting out by dealing with Gnumeric. It is simpler and smaller than Xlsx, and, more important, already has a test for an unexpected prefix, since, at some point, it changed its generic prefix from gmr to gnm. I added support and a test for that some time ago, but almost certainly not in the best possible manner. The code as changed for this PR seems simpler and less kludgey, both for that exceptional case as well as for normal handling. My hope is that this change can be a template for similar Reader changes for Xml, Ods, and, especially, Xlsx. All grandfathered Phpstan issues with Gnumeric are fixed and eliminated from baseline as part of this change.
Static vs. non-static in 5 places.
There was a problem hiding this comment.
I'm glad my comment was helpful (and hope it didn't sound too critical; XML namespaces are confusing). :)
I did a quick experiment with XlsxReader the other day, and found that a number of places use $foo['bar'] to access attributes, and fail if you select the namespace explicitly. They'll need to be tracked down and either converted to $foo->attributes()->bar, or have $foo = $foo->attributes() added above.
(The reason has to do with an oddity in the XML Namespaces standard, where an element with no prefix is in the default namespace, but an attribute with no prefix has no defined meaning.)
Adopt a suggestion from @IMSoP affecting listWorkSheetInfo, which uses XMLReader rather than SimpleXML for its processing.
PR PHPOffice#2024 was pushed last night, causing a Phpstan problem with this member.
Suggestions from Mark Baker - strict equality test, more descriptive variable names.
|
@IMSoP Critical, not nearly as critical as the people that demand that we solve the namespace problems without ever making any suggestions about how to resolve it... thanks for the guidance on how it should be done |
There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment #860 (comment) in issue #860 by @IMSoP has triggered an idea about how to proceed.
Although the issues exclusively concern Xlsx format, I am starting out by dealing with Gnumeric. It is simpler and smaller than Xlsx, and, more important, already has a test for an unexpected prefix, since, at some point, it changed its generic prefix from gmr to gnm. I added support and a test for that some time ago, but almost certainly not in the best possible manner. The code as changed for this PR seems simpler and less kludgey, both for that exceptional case as well as for normal handling.
My hope is that this change can be a template for similar Reader changes for Xml, Ods, and, especially, Xlsx.
All grandfathered Phpstan issues with Gnumeric are fixed and eliminated from baseline as part of this change.
This is:
Checklist:
Why this change is needed?