Hi Matthias,
Ok for keeping support for both field name and field alias. This sounds
right to me.
For the attribute table, I would prefer a context menu button (hamburger
style) for the horizontal header instead of tooltip, as the latter are
often not well known by users (or they discover tooltips randomly)
Thanks for your work !
Michael
2014-09-11 9:28 GMT+02:00 Matthias Kuhn matthias.k...@gmx.ch:
Hi Michael and Martin,
On Wed 10 Sep 2014 07:38:15 PM CEST, kimaidou wrote:
Hi all,
I am not sure using alias would be easier for the users. Some thoughts :
* sometimes aliases are quite complicated, like Contexte de
l'édition for a field named context. We would need to escape
properly aliases in expressions. And in this example, the real field
name is much easier and shorter thant the alias
* aliases can vary between projects or even between duplicate layers
in the same project, whereas field names are stable. If I cannot reuse
some expression for the same source table because I use different
aliases, I would spend more time to rewrite the expressions ( except
if we allow to use both in expression, but the user must then do the
right choice)
Disabling support for field names is not an option. Support would be for
both in parallel.
Field names can can be written in double quotes already, so the only thing
that will need to be escaped are double quotes (which are probably rarely
used in alias names).
The one thing that needs a decision is what the expression builder inserts
into the expression when the user chooses a field there. I would not mind
making the usage of aliases there optional.
* I think the problem is more that as soon as you use alias for some
field, it is then very difficult to find back what is the real name
of the column in the source table : aliases are displayed instead of
the column in every part of the Gui, which is fine but sometimes not
wanted. For example, I would love to have a button in the attribute
table which let me toggle between the aliases and the real field names
as the table header.
They would be listed both in the expression builder: Alias (field_name),
so you would have one more place where you have the combination.
In the attribute table, I would prefer to have it either in a context menu
of the horizontal header. Another approach would be a tooltip (where I
wanted to add the field comment anyway).
2014-09-10 19:00 GMT+02:00 Martin Dobias wonder...@gmail.com
mailto:wonder...@gmail.com:
I am just wondering... how the aliases would be made accessible to
QgsExpression? Would be a map of aliases from vector layer set to each
QgsExpression instace? Or extend QgsFields to support also aliases? Or
something completely different? :-)
I did not put any thoughts into the implementation yet. But I was thinking
about the second idea (saving aliases in QgsField) before. I think it would
be better suited there than keeping it separately. Are you sceptical
concerning this approach?
Best
Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
