id to form primitives? #531

New issue

Open

opened 2026-03-04 01:05:47 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:05:47 +03:00

Owner

Originally created by @marioemmanuel on GitHub (Apr 16, 2022).
Original GitHub issue: https://github.com/rivo/tview/issues/724

While exploring tview as a data front end tool, I am finding myself writing sample code as:

customerForm.GetFormItemByLabel("VAT ID").(*tview.InputField).SetText(c.vatId));

I am wondering if having an additional reference or id field (similar to what ID HTML attribute does for HTML front ends) would be helpful. In this case the name of the struct variable is c.vatId, but the label is VAT ID so somehow you need to handle both and if you decide to change the label that implies modifying more code.

It would be easier if you could write something like:

customerForm.GetFormItemById("vatId").(*tview.InputField).SetText(c.vatId));

The reason being that c.vatId can be referenced using reflection as reflect.ValueOf(&c).Elem().FieldByName("vatId") which opens more potential to better organise the application without using frameworks or complex architectures.

So we could separate the actual display label from the form field Id and just know that "vatId" is the field both in our backend data structure and in the Form element.

I know this could trigger many passionate opinions and unrequested dogmatic advises on how an application shall be architected -hopefully it does not-. The purpose of this comment is to raise the question on if "ids" could be helpful. To me they would be as you just need to reference fields by its Id both in the Form and in the underlying application data structures.

Originally created by @marioemmanuel on GitHub (Apr 16, 2022). Original GitHub issue: https://github.com/rivo/tview/issues/724 While exploring tview as a data front end tool, I am finding myself writing sample code as: `customerForm.GetFormItemByLabel("VAT ID").(*tview.InputField).SetText(c.vatId));` I am wondering if having an additional reference or id field (similar to what `ID HTML attribute` does for HTML front ends) would be helpful. In this case the name of the struct variable is `c.vatId`, but the label is `VAT ID` so somehow you need to handle both and if you decide to change the label that implies modifying more code. It would be easier if you could write something like: `customerForm.GetFormItemById("vatId").(*tview.InputField).SetText(c.vatId));` The reason being that `c.vatId` can be referenced using reflection as `reflect.ValueOf(&c).Elem().FieldByName("vatId")` which opens more potential to better organise the application without using frameworks or complex architectures. So we could separate the actual display label from the form field Id and just know that `"vatId"` is the field both in our backend data structure and in the Form element. I know this could trigger many passionate opinions and unrequested dogmatic advises on how an application shall be architected -hopefully it does not-. The purpose of this comment is to raise the question on if "ids" could be helpful. To me they would be as you just need to reference fields by its Id both in the Form and in the underlying application data structures.

kerem commented

2026-03-04 01:05:48 +03:00

Author

Owner

@marioemmanuel commented on GitHub (Apr 24, 2022):

Another two use cases where this is useful:

If you have "Address Line 1", "Address Line 2", "Address Line 3" you might want to add three input fields but just label the first "Address Line" and leave empty the other two. In that case having this "dummy" IDs would be good.
If you have an application where labels change depending on the language selected, having a common "dummy" ID to retrieve an exact form element is really helpful.

The "dummy" ID would not require any special logic as it is just another way to reference an item, and it would provide the same utility that the HTML ID attribute.

@marioemmanuel commented on GitHub (Apr 24, 2022): Another two use cases where this is useful: 1. If you have "Address Line 1", "Address Line 2", "Address Line 3" you might want to add three input fields but just label the first "Address Line" and leave empty the other two. In that case having this "dummy" IDs would be good. 2. If you have an application where labels change depending on the language selected, having a common "dummy" ID to retrieve an exact form element is really helpful. The "dummy" ID would not require any special logic as it is just another way to reference an item, and it would provide the same utility that the HTML ID attribute.

kerem commented

2026-03-04 01:05:48 +03:00

Author

Owner

@rivo commented on GitHub (Dec 17, 2022):

I agree that selecting items by label is not optimal, specifically for your second point. (Although I do wonder if you are actually having that problem in an application of yours or whether you listed a problem that "might" occur some time in the future. I have not had any other complaints about this yet.)

The first point can now be solved by adding a TextArea to the Form.

So yes, in retrospect, I would do it differently, and an ID would be a possible solution. But now I need to think about backwards compatibility. The Add... methods cannot be changed. And adding new versions for all of them on top is also not something I want to do. Currently, I cannot think of a good way to add IDs.

Alternatively, I could easily add a GetItemByIndex(index) function. This would not be as clean as ID strings but it could solve the issue where you cannot rely on labels.

@rivo commented on GitHub (Dec 17, 2022): I agree that selecting items by label is not optimal, specifically for your second point. (Although I do wonder if you are actually having that problem in an application of yours or whether you listed a problem that "might" occur some time in the future. I have not had any other complaints about this yet.) The first point can now be solved by adding a `TextArea` to the `Form`. So yes, in retrospect, I would do it differently, and an ID would be a possible solution. But now I need to think about backwards compatibility. The `Add...` methods cannot be changed. And adding new versions for all of them on top is also not something I want to do. Currently, I cannot think of a good way to add IDs. Alternatively, I could easily add a `GetItemByIndex(index)` function. This would not be as clean as ID strings but it could solve the issue where you cannot rely on labels.

kerem commented

2026-03-04 01:05:48 +03:00

Author

Owner

@SamWhited commented on GitHub (Dec 17, 2022):

Although I do wonder if you are actually having that problem in an application of yours or whether you listed a problem that "might" occur some time in the future. I have not had any other complaints about this yet

FWIW, I have also run into this exact problem a number of times in real world applications and ended up using custom lists or another UI toolkit in several cases. I thought I had filed an issue about this as well, but I guess not.

@SamWhited commented on GitHub (Dec 17, 2022): > Although I do wonder if you are actually having that problem in an application of yours or whether you listed a problem that "might" occur some time in the future. I have not had any other complaints about this yet FWIW, I have also run into this exact problem a number of times in real world applications and ended up using custom lists or another UI toolkit in several cases. I thought I had filed an issue about this as well, but I guess not.

kerem commented

2026-03-04 01:05:48 +03:00

Author

Owner

@marioemmanuel commented on GitHub (Jan 21, 2023):

To me it was the reason for withdraw the toolkit. I was doing a sample toy application, nothing commercial or serious.

@marioemmanuel commented on GitHub (Jan 21, 2023): To me it was the reason for withdraw the toolkit. I was doing a sample toy application, nothing commercial or serious.