LWC has compatibility problems with QGIS. While refactoring and testing the QgisProject class, I realized the getXmlLayer2 method was returning the result of an outdated xpath request on the XML of the .qgs. There is probably some other outdated code pieces somewhere in the files, the only thing I've seen in the code that is checking compatibility is a big if statement that is executing the same code with tiny changes depending on the Qgis Version (QgisProject::readLayersOrder).
Proposed Solution
To avoid aving if forests checking Qgis version and executing the almost same code but still being compatible with the maximum amount of Qgis version, I think each time QGIS releases a new version with a modification of the .qgs architecture, we should implement a class QgisProjectX_X extending QgisProject that will redefine only the methods whose behavior should differs from the default one.
With this solution, LWC can be compatible with every QGIS version, we just have to check it once and instantiate the right class so the code will be easy to modify without breaking everything, it will also be lite (except for really big release like QGIS2 -> QGIS3, there shouldn't be more than a few lines to modify with releases), readable and easily testable.
Example(s)
class QgisProject //Compatible with 2.18 but not with 3.X
{
...
protected function getXmlLayer2($xml, $layerId)
{
return $xml->xpath("//maplayer[id='{$layerId}']");
}
...
}
class QgisProject3_2 extends QgisProject // compatible with Qgis 3_2
{
protected function getXmlLayer2($xml, $layerId)
{
$layerList = $xml->xpath("//maplayer");
foreach ($layerList as $layer)
{
if ((string)$layer->id === $layerId) {
return $layer;
}
}
return null;
}
}
LWC can now execute the right xpath Query whatever the QGIS Version of the project is, you just have to instanciate the right class and changes are really small.
Affected Files
(required if applicable)
Performance Implications
None that I can see.
Backwards Compatibility
If applied correctly, LWC could be compatible with every QGIS version past and future.
Lizmap RFC:
Date 2020/09/01
Author Adrien Lagroy de Croutte (@alagroy-42)
Version Lizmap-Web-Client 3.3.10
Summary
LWC has compatibility problems with QGIS. While refactoring and testing the QgisProject class, I realized the getXmlLayer2 method was returning the result of an outdated xpath request on the XML of the .qgs. There is probably some other outdated code pieces somewhere in the files, the only thing I've seen in the code that is checking compatibility is a big if statement that is executing the same code with tiny changes depending on the Qgis Version (QgisProject::readLayersOrder).
Proposed Solution
To avoid aving if forests checking Qgis version and executing the almost same code but still being compatible with the maximum amount of Qgis version, I think each time QGIS releases a new version with a modification of the .qgs architecture, we should implement a class QgisProjectX_X extending QgisProject that will redefine only the methods whose behavior should differs from the default one. With this solution, LWC can be compatible with every QGIS version, we just have to check it once and instantiate the right class so the code will be easy to modify without breaking everything, it will also be lite (except for really big release like QGIS2 -> QGIS3, there shouldn't be more than a few lines to modify with releases), readable and easily testable.
Example(s)
LWC can now execute the right xpath Query whatever the QGIS Version of the project is, you just have to instanciate the right class and changes are really small.
Affected Files
(required if applicable)
Performance Implications
None that I can see.
Backwards Compatibility
If applied correctly, LWC could be compatible with every QGIS version past and future.
Votes
(required)