Suggestion for Field Name / ID Improvement

[George Pegos]

Hello Team,

I am considering sending the following suggestion to support, and I would appreciate your feedback before I do.

Currently, each field has a property called "name". Based on this property, fields are referenced in code using field(name).

For example, let’s assume I created a field with the name "FieldName", and I have already written code for a JavaScript field using this reference. Later, I realize that "FieldName" is no longer the best name and I would like to rename it to "FieldNameNew".

At that point, I am forced to search through all of my code and replace every instance of:

field("FieldName")

with:

field("FieldNameNew")

My suggestion would be to rename the current "name" property to "id", and introduce a new property called "name".

All code references would then use the stable "id" value (which means no changes would be required for existing code), while the field would be displayed in the UI using the "name" property if it is not null, otherwise it would fall back to the "id".

This would also make it easier to avoid writing code with field names in Greek or other display-oriented labels.

What is your opinion?

Thank you,
George

[Mmm]

Эти методы существуют с момента появления Правил, но я не видел их описание в документации.

let e = entry(); 

let value = e.fieldById(field1_id); //чтение поля 1 по его id 

e.setById(field2_id, value); //установка значения для поля 2 по его id 

Больше интересует сама возможность получения информации о полях.

Предложите автору реализовать объект JavaScript, который будет содержать информацию о полях:

– name (имя поля);

– id (id поля);

– type (тип поля, например как указан в шаблоне библиотеки: ft_string, ft_boolean, ...);

– linkLibId (id библиотеки для полей ссылок);

– libId (id библиотеки, которой принадлежит поле);

– другие полезные сведения.

Чтобы не изменять значения полей в скриптах при изменении имени поля можете создать глобальную переменную и при необходимости вносить изменения в нее.

const field1 = 'Όνομα πεδίου στα ελληνικά';

message( entry().field(field1) );

понедельник, 13 апреля 2026 г. в 09:08:31 UTC+3, gpe...@gmail.com:

[David Gilmore]

How would this ID field be determined? By the order it appears in the Library (1, 2, 3...)? What happens when the order of the fields is rearranged? Which means a more complicated ID field value. And now the user would have to constantly determine what that ID actually is, as it would not be as easily remembered.

But agree that there could be improvements in this area. What I think would solve the problem is to approach it another way. It would be nice to have a global "Search" and "Search and Replace" script functions, so that the user could go into his library and search the entire Javascript scripts for specific strings.

[Bill Crews]

Since JavaScript was introduced in Memento, I've always thought we needed a Field object that would have properties like those described, and we've had conversations about it, but there has never been agreement to offer it, for whatever reason. Let's urge him to do it now.

--
You received this message because you are subscribed to the Google Groups "mementodatabase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mementodataba...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mementodatabase/8ebc323a-965e-426a-8278-76c34f406153n%40googlegroups.com.

[Mmm]

Мне известен только один способ получения ID поля:

1. Создать Правило-Действие в записи.

2. Добавить задачу "Обновить поле" и выбрать поле, для которого нужно узнать ID.

3. Повторить пункт 2 для других полей, для которых нужно узнать ID.

4. Полученное правило преобразовать в скрипт.

5. В результате будут известны ID полей.

Изменение имени или очередности поля в библиотеке не меняет ID поля.

Не проверял изменение ID, если преобразовать тип данных поля или скопировать библиотеку.

Я не считаю, что использование ID полей более удобно. 

Мне нравится предложение Давида о поиске и замене. 

Добавил бы ещё возможность поиска в редакторе скриптов и быстрый переход по номеру строки.

понедельник, 13 апреля 2026 г. в 17:35:03 UTC+3, bill....@gmail.com:

[George Pegos]

What I am suggesting is that each field should have a separate line where the user can define the ID manually, exactly the same way you currently define the field name and the field hint.

For example, I could create a new boolean field and set its ID as "boolean_terms", while the display name could be something like:

"Yes, I have read and fully understand the instructions you have given. And I will......."

Right now, in scripts, I am forced to use:

field("Yes, I have read and fully understand the instructions you have given. And I will.......")

but with the way I propose I could use:

field("boolean_terms")

As I have untouched the ID that I have manually set I could change the name of a field as I want.

Thanks,

George

To view this discussion visit https://groups.google.com/d/msgid/mementodatabase/1fef6e07-10c3-40b7-bf01-81ee54f0fe2fn%40googlegroups.com.

[王玲德]

I previously contacted the author via email, hoping to add a JavaScript script that could be used across all libraries. He suggested that I use GitHub to manage the script, so that whether it's making modifications or replacing the name you mentioned, I can do it with the help of software like VSCode

[Bill Crews]

I don't claim to be an expert here, but I'm pretty sure the ID is used internally within Memento as the unique primary key in the embedded SQLite memory-based relational DBMS. The value of the ID is included as a column in CSV files, if you want to locate it there for whatever reason. 

It's probably because of my impairment, but I am confused as to why you feel the need to do all this. I've read your messages, but I just don't get it. I think there's a possibility that you're overthinking the situation. 

I don't know that Mmm has an answer for you, but his information is almost if not always valid. 

To view this discussion visit https://groups.google.com/d/msgid/mementodatabase/CA%2BzRxo%2BaWP8FTt%3D6p08b1DBW5CE6tTenZnKs%2BswgMatAJGOj3A%40mail.gmail.com.

[Mmm]

Я не думаю, что переход объекта entry() с концепции "имён полей" на концепцию "псевдонимов полей" актуален.

С таким же успехом Пользователь может изменить псевдоним поля и скрипты станут неработоспособны.

Выше уже писал, что можно использовать глобальные переменные для имен полей.

Эти переменные можно разместить в одном общем скрипте "Имена полей" и использовать во всех других скриптах и триггерах библиотеки.

При изменении имени поля будет достаточно изменить значение переменной, а не искать упоминание имени поля в разных местах кода.

Пример:

//Общий скрипт

const boolean_terms = "Yes, I have read and fully understand the instructions you have given. And I will.......";

//Скрипт действие в записи

let e = entry(); 

message(e.field(boolean_terms));

Можно рассмотреть предложение о псевдониме поля с другой стороны.

Сейчас есть возможность показать или скрыть имя поля. 

Потребуется дополнительная настройка "Показать псевдоним" с возможностью указания этого псевдонима.

Тогда концепция "имён полей" в скриптах не будет изменена, а в записи вместо имени поля будет виден "псевдоним поля".

Но я далек от мысли, что это очень востребовано для всего сообщества Пользователей.

вторник, 14 апреля 2026 г. в 06:59:05 UTC+3, bill....@gmail.com:

[George Pegos]

Because many of you seem confused, please allow me to make it even simpler and much more easier to implement.

For every field type:

1. The current field name remains unchanged.

2. A new text area (how else could I call it?) is created (let’s call it field text, so I can refer to it), placed below the field name and field hint, and before the properties. In this area, the user can write the text that will be displayed in the GUI as name.

How it would work:

1. If field text is null, then the title displayed in the GUI will be the field name.

2. If field text is not null, then this value will be displayed in the GUI, similar to how the field hint is currently shown now in linked fields.

3. Any script will continue to work exactly as it does now, based on the field name, regardless of what field text is, meaning field(name).

4. I would also be able to call field(name).text, which would return the value of field text.

Regarding the problems this would solve, as Bill asked, I would mention the following:

a. All of my fields have Greek names. As a result, my code calls field() using Greek text as the argument. As you know, in Greek we use accent marks, and if I forget an accent somewhere, I cannot access the field.

field("Όνομα Χρήστη") is not the same as field("Ονομα Χρηστη").

b. In some libraries, I have fields with very long names, such as:

• "Are you sure you want to make this change?"
• "I accept the changes that may result from the above conditions"
• "Use this photo in the Transactions Library as the main photo"

Now imagine when I need to call the field() function for those fields in 3 or 4 different JavaScript fields and in 3–4 different automations.

c. Continuing the above example, imagine needing to call those same fields from linked libraries.

d. What happens if I realize I no longer like the name of a field and I want to rename it, while that field is referenced in 4 JavaScript scripts and 6 automations? I would need to make 10 changes. And what if it is also referenced in 5 other libraries?

e. Think about the possibility of changing the displayed text through JavaScript, for example:

e.set(name).text = "new text for the field"

This would allow truly multilingual libraries.

By pressing a button:

Button "Change language to English" pressed → execute code

the fields could automatically change their text to show into English.

A real scenario that I had before sent:

I have a library called contacts that contains businesses and individuals. Naturally, around 20+ other libraries are linked to it, such as:

• transactions (one contact made a transaction with another contact)
• car service (who took the car to which workshop)
• medical (who visited which doctor)
• software (who bought software from whom)

and many more. As you see I link to contacts library at least twice times.

In the contacts library, I had a field that I was calling from all the other libraries with the name "Επώνυμο" (surname in Greek), and I needed to rename it to "Surname".

Can you imagine what happened?

I was forced to create a calculated or JavaScript field with the name "Επώνυμο" just to avoid making changes in every library. And I had to do the same thing for 12 fields that I renamed from Greek to English.

Tell me, isn’t that absurd?

If I had:

name = surname

text to show = Whatever

then I could change the displayed text in the GUI at any time without affecting the code.

Thanks,

George

[David Gilmore]

[quote]

For every field type:

1. The current field name remains unchanged.

2. A new text area (how else could I call it?) is created (let’s call it field text, so I can refer to it), placed below the field name and field hint, and before the properties. In this area, the user can write the text that will be displayed in the GUI as name.

How it would work:

1. If field text is null, then the title displayed in the GUI will be the field name.

2. If field text is not null, then this value will be displayed in the GUI, similar to how the field hint is currently shown now in linked fields.

3. Any script will continue to work exactly as it does now, based on the field name, regardless of what field text is, meaning field(name).

[/quote]

Does the "Field Hint" attribute in the edit field not do this for you? Text in the "Field Hint" attribute will show as slightly dimmed text in the GUI for fields that are empty, and get replaced when the user enters his/her own text.

Also, there is no "label" field type, but you can simulate one by creating a text field, setting "Read Only" to true, and setting the "The Field Name" (shows the field name in the GUI) to false. The "Field Hint" text will show up as if it was a label. You can also hide or show fields depending on what state you are in (edit or view).

I think your suggestions, although with merit, may be to specific to be useful to everyone. It will be Memento's decision of course, but I suspect there might be some reluctance to implement them. In the meantime, you can do what you want via clever programmatic means.  If you need help in a specific issue, this forum can help. But please be aware that some of those needs are already met, you just have to be flexible to utilize them.

Also, Memento staff does not always monitor this forum, so new suggestions do need to be submitted directly to Memento.

[George Pegos]

Thank you all for your replies, I really appreciate it.

Thank you for your response, David.

Regarding what you mentioned, I would say that the current field hint is not what I am describing. I do not want something that appears only when there is no text entered. What I want is for the field name shown in the GUI to be changeable without affecting the code in calculated fields, JavaScript fields, and scenarios, and without changing how that field is referenced from another linked library when I decide to rename it.

I would appreciate to give me a suggestion on how I can rename a field name without having to update all scripts in the same library and in linked libraries.

Regarding your suggestion, Mmm, about:

const boolean_terms = "Yes, I have read and fully understand the instructions you have given. And I will.......";

Yes, it is possible, but I would need to do this in every JavaScript field and also in a shared script for scenarios. And what should I do in the libraries where I already call that specific field?

Yes, from a programming perspective I can create workarounds for all the problems I mentioned. I can even create JavaScript fields with the old field names before renaming them. But how DRY is that code, if I have to change every line or to add a const in every script?

How can I provide different languages to different users in a library for the field names?

What I am describing is essentially what Mmm described more successfully as Show alias. I think he describes it better than I did.

I have already presented in my previous email five reasons why I believe this addition could be helpful.

Thanks again,

George

To view this discussion visit https://groups.google.com/d/msgid/mementodatabase/98743a58-c161-466f-ad20-2e233ba2f09cn%40googlegroups.com.

[Mmm]

Все, что описывается в теме, приближает к необходимости создания нового объекта JavaScript field(). 

Именно нового объекта, а не метода объекта entry().

Memento не позволяет изменять свойства полей с помощью скриптов.

Автор темы стремится именно к этому.

Если анализировать темы форума, то, в той или иной мере, Пользователи задаются вопросами изменения свойств и характеристик полей с помощью скриптов.

Есть вопросы видимости полей, создание псевдонимов имен, запрета редактирования, изменение других свойств.

Но нужно помнить, что Memento больше ориентируется не на программистов, а на обычных Пользователей. Об этом говорит появление Правил (упрощённый вариант программирования без знания основ JavaScript).

Будет замечательно, если на первом этапе появится объект field() с возможностью чтения основных свойств полей и библиотек, которым они принадлежат. Об этом писал выше. 

На втором этапе – изменение свойств полей с помощью скриптов. Например, о чем говорит автор темы.

В любом случае, предложение автора темы может иметь место в дальнейшем развитии Memento. 

Будет интересно увидеть в теме точку зрения разработчика.

вторник, 14 апреля 2026 г. в 19:39:20 UTC+3, gpe...@gmail.com:

[Bill Crews]

Well, I'm sorry, George. I guess I'm finally getting too old to think through such things as this. I can't even tell what the context behind all this is. None of the nouns seem to have antecedents. So, I'm bowing out. Maybe no one else is confused. Good luck with it. 

-Bill

[Bill Crews]

If there were a field(), it wouldn't be an object. Would it be a global function? I think not, but rather a method of the Library object. So, we might have let field = lib.field(What?), and it would return a Field object. What then would the field() method take as an argument? I'm not able to follow all the dialogue in this thread so forgive me if I'm missing something basic, but in Memento, the unique identifier of a field, within a library, is the field name string. I assume all your talk about IDs has been about entries and not fields, right? So, that argument would be the field name., like lib.field("My field"); If the method returns null, there is no such field in the library.

So, field() would be the Library method name, and Field would be the object name. 

[Mmm]

lib().fields(); //может возвращать массив имен полей

lib().fields().asObjects(); //может возвращать все, о чем говорилось выше

Дальнейшие действия, как с массивом объектов. Как объекты будут называться - на усмотрение разработчика.

вторник, 14 апреля 2026 г. в 21:35:29 UTC+3, bill....@gmail.com:

[Bill Crews]

Are these existing methods or your proposed methods? They sound good to me. 

Thanks for reminding me about scripts.memento.database.com. Now I can monitor that with distill.io and keep my copy up to date. 

-Bill

To view this discussion visit https://groups.google.com/d/msgid/mementodatabase/4e9c7e98-3bdc-4572-b5f7-240dabb1cf71n%40googlegroups.com.

[Mmm]

Первый существует:

https://scripts.mementodatabase.com/script_api/library/#fields

Второй – предложение.

вторник, 14 апреля 2026 г. в 22:27:35 UTC+3, bill....@gmail.com: