[Qgis-developer] mapserver plugin, qgs project xml and label-elements

[Martin Dobias]

On Mon, Mar 29, 2010 at 10:28 AM, Richard Duivenvoorde <richard at duif.net> wrote:
> Hi Martin,
>
> my 'problem' with using the context of the tag is that the minidom retrieves
> ALL child label-elements from the maplayer element, and I do not know an
> easy name to distinguish the right 'label' from all the labels I retrieve
> from the maplayer element...
>
> -maplayer
> \-LABEL   // 1 or 0 == haslabel
> \-uniquevalue
>        \-symbol
>                \-LABEL // txt == legendlabel
> \labelattributes
>        \-LABEL fieldname=X text=Y  // actual labels

Right, so you can take all returned <label> elements and check what is
their parent (using parentNode attribute) to determine their context.


> Your argument about 'incompatibility for the projectfiles'. Is that valid?
> We do not guarantee backwards compatibility do we? And it makes the project
> file more understandable and easier to use for plugin builders.

Well, I wasn't really clear. We try not to modify project file format
among releases of QGIS. Ideally, project created in 1.0 should work
perfectly in 1.4 and vice versa. But this is not always possible: so
if we do any changes to project file format, we aim to keep
compatibility with projects from older releases. There is a small
framework for transformation of older project files to newer project
files (see QgsProjectFileTransform). If there are any
incompatibilities, the older project file is first transformed
on-the-fly to work with current version and then loaded (as if it was
a project file from current version). So, when a change in project
file format is introduced in qgis 1.7, then qgis 1.3 probably will
have some problems reading it. Therefore we try to avoid such changes
if they're not necessary.

I hope other devs have the same opinion, if not, please tell me :-)

If we changed the names of <label> element tags for 1.5, the new
projects will get incorrect labeling settings in older versions of
QGIS. That's why I think it's better to keep things as they.

> The plugin is fortunatly a 'standard qgis plugin', so is always delivered as
> is with a current version. And will work with that version of the project
> file format :-)

If you parse the xml code manually, you may need to take care of the
differences too (or tell the user he needs to save the project in the
qgis version the plugin expects). That's another win of using
QgsProject class: it will handle the differences automatically and you
don't have to bother with it.

Cheers
Martin