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 <[email protected]
<mailto:[email protected]>>:
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
