to give the chance to save the ADD NEW record as a draft (after any changes possibly) then to save it definitely in a second time when disconnection may happen (to rescue it back asap).
to avoid to show the CODE of the Combo Box or the Boolean field as a title of the field (description of the showed data).
Some time it happen to GROUP BY the chosen SWITCH but obviously do not help to see the values TRUE and FALSE as a description, so the better would be to add a different description chosen by the developerā¦
This one is already possible through the use of custom forms.
With a custom form, all user inputs are initially written to User Specific Columns, and only committed to the tables with an explicit Add Row or Set Column Values action step.
This means that - if you set it up correctly - a user could restart the app half way through filling out a form, and then return to where they were with all previously entered values still intact.
You can do this with an IF column. If true, then return whichever description you wantā¦else return a different description. Then use the IF column value for grouping.
Hi David,
the above example is just a simple example that shown the GROUP BY made by a SWITCH that actually indicate the division by the Selected and Non selected, what @Jeff_Hager wrote is correct, with a IF column we can skip this, but this may going to make the DB bigger and in any case will work only for the Boolean field (where I have only 2 values), in case of Combo is different:
in those above example Iām using the CATEGORY field to GROUPBY but actually this CATEGORY is just a code that is contained in another table, so would be better for me not to show the CATEGORY CODE but the CATEGORY DESCRIPTION, thatās will make the result more comprehensible.
I hope Iāve clarified it.
About the DRAFT Solution, what proposed by @Darren_Murphy is definitely a good solution but it is a short cut not the perfect way to do that.
If we have a native rollback to the edited data (the DRAFT made after every changes in every fields by the user) would be much better and will avoid the duplication of fields , that indeed in case of changes of the DB structure should be taken in great consideration.
I hope is clear also this.
An IF column wonāt make the database bigger. Itās computed on the userās device. An IF column is not a stored value.
In your combo example, all you need to do is create a single relation column to link the category code to the code in the category sheet. Then use a Lookup column to get the full description. That lookup column is what you use for grouping.
I wrongly said it, not the physical DB but the whole structure.
I mean you have to add many IF column as many fields you have to convert, but maybe for the case of Boolean is not a big deal, normally we donāt have so many to expose, generally are hidden info.
But in case of the DROPDOWN list is different, we use many in many circumstances, then to create many relations and relevant LOOK fields for this only purpose may result in a kind of tragedy to handle those in a later time, there will be more fields and relations that later we should be worried about in case of any changes, it is a solution but definitely I donāt think this is the solution. I would prefer to have the chance to create a specific DROPDOWN list table, I mean a native table created with the only purpose to be used as a DROPDOWN combo, in this case the system can easily get out the description from a predefined structure.
Well, I guess itās all in your perspective. I have a lot of computed glide columns that do various things. Relations and lookups are powerful and allow you to reference data from several locations without having to duplicate data. Your category example seems like a really good case for using a relation and lookup. This allows you to leave the category code as is, but change the description in only one table and it will auto populate that description throughout the app. What I understood from your original post was that you wanted to specify somewhere (maybe you meant in the group by settings), what each category code should be translated to. The problem is that it is not scalable and not a data driven solution. That means you would have to edit the app every time you want to add a new description or change a description instead of just updating the description in only one location in the category sheet.
I donāt know how many times you would have to create a relation/lookup, but I donāt know of any better way. Thatās how relational databases work. I have a āchoicesā sheet in my app where I store all my choice options for several different types of choice components. If my choices have an underlying code, then I store the code in whichever sheet my choice component is writing to. I wouldnāt want glide to guess and decide if a code matches something in that choices sheet. I want control of that using a relation and lookup to make sure Iām getting the correct description for that code. To me it seems perfectly normal to do it that way. In some cases, I donāt need an underlying code, so the full description is what I store for the selected choice.
I think any sort of an alternative would be more of a tragedy. But, maybe Iām not fully undestanding why you would think it would be more of a problem. To me it seems normal and the best way to structure the data so it can scale and grow when you add more choices or categories. Just add more categories to your categories sheet and the rest of the app will just work.
Not really, probably I was not able to explain myself correctly.
What I mean is that the system (Glide) should take by itself the description from the code that is in another table.
Perhaps in my example the Table Category is just structured with 2 fields āCODEā and āDESCRIPTIONā, so Glide should determine that this field is belonging to a Class Table type Combo and then automatically propose to get the description as a output result or in any case to choose what kind of value to show out.
I sincerely dont like to use relations for this scope, as I said to avoid to have many fields into the structure, but Im agree that is currently the only solution.
I think I understand, but how is glide suppose to know what and when to use that category table. Computers only know how to do things when humans program them to to know. Thatās where Iām saying that I donāt want glide to guess and decide if a code should have a description and when, where, and which column to look for it. I want control of that so that I know it works how I designed it and will work as expected on the future. Then I can look at the data in the data editor and know right away that the lookup is returning the correct value. Again, itās all perspective. Thatās just how I feel about it. I understand you, but I think it could have narrow use case. Either way I think you are going to have to have a setting or a column of some sort to make that work. Glide has mentioned the possibility of redoing how relations work, so maybe a lookup column would have the relation logic built into it. I donāt know if or when that will happen.
Glide should not decide actually, but only give me the possibility to choose what value to show.
Letās make an exmple:
instead to create a TEXT field Im going to create a Combo Field (that is like text field but with the property ācomboboxā) where it is supposed to be associated to a Table (class Combo or just a table), so when you are creating the field the Table must be already there and be added into the field property.
so when you are going to use the Field Combo Glide should recognize it and propose which value you want to show out, like in the following example:
Thatās will avoid to add more relation table and consequently Look fields.
EDIT: sorry, last Image would have been shown the GROUP BY with the field name 'New Column C' instead of Category that in my example is actually a Table
