Column Name - PLEASE HELP!!

[Joseph_Seddik]

Hello,

I'd much appreciate your help on this one. 

I want to write an expression, and put it in some columns of the table. The outcome of this expression would depend on the column name. 

Is there a notation, a function, or anything that will give the column's name NOT its value. For example: "Column A", "Date", "Customer Name", "Date of activation", "My own precious column", etc.? Any possibilities please? 

In AppSheet logs, we can see information like:

• "EvalType": "COLUMNSET",
• "ColIndex": 1,
• "ColName": "resID",
• "TableName": "Reservas",

Are these system variables or alternatives available to app creators? Can they be accessed?

Please please help!

[Aurelien]

Hi @Joseph_Seddik 

I'm afraid your question is unclear to me.

Can you be more specific, with an example maybe ?

What are you looking to achieve with the expression you are looking for ?

[Joseph_Seddik]

Cher Aurelien! 

Thanks much for responding.

I want to have an expression in the Display Name of the column that gives a different result based on the Column Name. For example:

TEXT( ANY( SELECT(Table[Display], AND(
   [option] = "someOption",
   [column] = CONTEXT("ColumnName")
))))

This is exactly what I would like to be able to write. Of course CONTEXT("ColumnName") does not exist, but just to demonstrate what I would like to have.

AppSheet already, naturally, captures the column's name, as we can see from the logs. My question is how can we use it. 

Thanks much!!

[Aurelien]

ok, thanks for further informations and context.

Based on my understanding:

- Display names can use whatever expression you wish. You could use, for example:

SWITCH(CONTEXT("ViewType"),

  "Table", "myDisplayNameForTableViews",

  "Form", "myDisplayNameForFormViews",

  "myDefaultDisplayName"

)

However, I don't think it's possible to use the column name, let's say "internal name", and use it in an expression.

Let me know if that's the answer to your question, I'm not sure of answering correctly ^^'

[Joseph_Seddik]

Thanks @Aurelien you understood perfectly. 

I actually needed exactly this: to use this "internal name" in an expression. If it is not possible, I guess I'll open a feature request for it then.

[Aurelien]

I'm just curious: why would you need such a feature ?

[graham_howe]

I definitely wanted a similar feature. In my case it was for role based security where I have a table of use roles and columns to indicate which table or view the role has access to. It would have been very easy in my show if expressions to use a single piece of code that looked up the role table for a column with the same name as the current view. Instead I had to hard code the relevant column in each show if. I demonstrated this in my tips and tricks post Flexible user role management where for example I have the following to restrict access to the Automation List

Index(SELECT(User Roles[Automation List], ([Role ID] = Index(Current_User[Role ID], 1))), 1)

The words Automation List are hard coded.

[Joseph_Seddik]

Sure! This idea applies to using data from a table instead of hardcoding everything in columns' expressions. Whenever you need a new category you can just add a new column in that table instead of changing the expressions in every column in your app. 

Our friend @graham_howe showed a very useful case. My case is similar but for something else.

I want to easily add new locales in my App that should support a lot of languages. So far, AppSheet way, is to hardcode every language for ALL columns in your app. I don't have to say anything about how terrible this is. 

If we could access this "internal name" that AppSheet already knows uses, not us, I could have done the following:

1. Create a Languages Table. 

2. Every Language will have one column. 

3. Rows will be the column names of my app 

4. I will then copy/paste the very same expression above in all columns just once. 

[bonameblisto]

Wouldn't it be better to go the other way?
Create table: ID, Lang, Text1, Text2, Tex3... etc

For "Display name" of column/action use lookup from that table
?

[Joseph_Seddik]

Data in columns? I don't see how this could be better, would you please explain to me your point of view? 

Thank you!

[bonameblisto]

---

@Joseph_Seddik wrote:

Data in columns? ... explain to me your point of view? 

---

No data. Only values for user-visible Display name

First
DisplaynameForAnyLangTable:

ID	Lang	Name1	Name2	Name3	etc
qwerty	en-US	First field	What you want	Enter IP here
asdfgh	ru-RU	Первое поле	Чего желаете	Введите IP-адрес
zxcvbn	pl-PL	Pierwsze pole	Czego chcesz	Wpisz IP tutaj
etc

Next
Display name property for column/action set to
=lookup(USERLOCALE(),"DisplaynameForAnyLangTable", "Lang", <Corresponding NameX column>)

[graham_howe]

Personally I would go with @Joseph_Seddik approach of a column per language, it feels more natural to me and for example using a quick edit in a table it would be relatively easy to add all translations at once. I might expand the table to have a column for [Table Name] as well as a column for [Column Name], that way it might be nice to group the view by table to see all those columns together.

Of course this is still irrelevant if you have to hard code the column names in each Display Name expression.

[Joseph_Seddik]

@bonameblisto Thank you!

From an expression's point of view it doesn't matter if the data is organized in columns or rows. I remember reading that LOOKUP is only an encapsulation of SELECT.

As @graham_howe said, this is counterintuitive, but it is not the main problem. From a DB perspective, lists should be avoided in columns. Also, please take to account that with every new value you add you'll have to regenerate the structure vs. just adding a new row through a form, and adding columns only when a new whole language set is added. 

In any case, as Graham also said, it doesn't matter in any case if you still have to hard code the column name in each field, and do countless saves. This is what we are trying to avoid. 

[graham_howe]

I suppose for total flexibility the translation table would have just 4 columns:

TableName, ColumnName, LanguageKey, DisplayName

This way neither adding new columns nor new languages would result in a regeneration of that table. It would be a nice design for an international app, but still a pain to maintain if we can't access the metadata.

[Joseph_Seddik]

Even better!! thank you. Then create dynamic slices using [languageKey] = USERSETTINGS("Lang"). 

I like it much!!

[Lukas_961026]

How u do that? can u explain me please?