Do you mean to give the field keys something more mnemonic
rather than just 1,2,3...? Or, do you mean skipping the
line so it doesn't waste a label? In the 2nd case, this can
be accomplished by deselecting the one line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IMHO, it is a interresting idea but a problem will appear in
the editing canvas preview. Because if you made a label with
field that are one digit of barcode for example, if you
place a ${first_number_barcode} instead of the digit '1' for
example, it will not render the result you're looking for
and the strings may overlap (it already happen now with the
example I give but it is not critically annoying yet). So
for this feature to be useful, it must have the possibility
in the text tool options to set a default value that will
represent the string that will be replaced.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like the idea, it actually makes a lot more sense in the
context of CSV being only one of many possible database
backends.
A similar feature was actually part of the 0.4.x codebase,
but was simplified for the 2.0.x codebase (it allowed you to
edit aliases rather than extract them from the underlying
database structure). I have always felt that the field
names could and should be more mnemonic but they should be
based on how they are named in the database. In fact, I
have assumed that once additional back-ends are created that
you would end up with an infinite set of possible field
names. Examples: ${1}, ${first_name},
${parent/mother/name/first}, and so on, depending on how
they are stored in the underlying database. For more
specific backends, such as the evolution data server, the
set of field names would be finite. So basically yes this
idea fits that model.
As far as the mismatch in size of the field versus the
contents, the opposite is also true: ${1} could store
something like "AVeryLongNameThatGoesOnAndOnAndOn," making
layout annoying as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As for "AVeryLongNameThatGoesOnAndOnAndOn", why not
make it optional so that you can have ${1} as now, or
${"AVeryLongNameThatGoesOnAndOnAndOn"} for the field
name. The use of quote marks in the second format could be
used to tell one type from the other.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=223712
Do you mean to give the field keys something more mnemonic
rather than just 1,2,3...? Or, do you mean skipping the
line so it doesn't waste a label? In the 2nd case, this can
be accomplished by deselecting the one line.
Logged In: YES
user_id=227421
Yes I do mean that, though it should be optional by a tickbox,
since not all CSV files will have it.
Logged In: YES
user_id=226667
IMHO, it is a interresting idea but a problem will appear in
the editing canvas preview. Because if you made a label with
field that are one digit of barcode for example, if you
place a ${first_number_barcode} instead of the digit '1' for
example, it will not render the result you're looking for
and the strings may overlap (it already happen now with the
example I give but it is not critically annoying yet). So
for this feature to be useful, it must have the possibility
in the text tool options to set a default value that will
represent the string that will be replaced.
Logged In: YES
user_id=223712
Also see Tracker item 990179.
I like the idea, it actually makes a lot more sense in the
context of CSV being only one of many possible database
backends.
A similar feature was actually part of the 0.4.x codebase,
but was simplified for the 2.0.x codebase (it allowed you to
edit aliases rather than extract them from the underlying
database structure). I have always felt that the field
names could and should be more mnemonic but they should be
based on how they are named in the database. In fact, I
have assumed that once additional back-ends are created that
you would end up with an infinite set of possible field
names. Examples: ${1}, ${first_name},
${parent/mother/name/first}, and so on, depending on how
they are stored in the underlying database. For more
specific backends, such as the evolution data server, the
set of field names would be finite. So basically yes this
idea fits that model.
As far as the mismatch in size of the field versus the
contents, the opposite is also true: ${1} could store
something like "AVeryLongNameThatGoesOnAndOnAndOn," making
layout annoying as well.
Logged In: YES
user_id=227421
As for "AVeryLongNameThatGoesOnAndOnAndOn", why not
make it optional so that you can have ${1} as now, or
${"AVeryLongNameThatGoesOnAndOnAndOn"} for the field
name. The use of quote marks in the second format could be
used to tell one type from the other.