I have two different list relations on a page - one based on a phone call relation and the other based on a meeting relation. I want to present the phone call list in the compact list layout and the meeting list in a calendar layout. But Glide applies the same layout to both the list relations even though the values come from different relations.
If I use multiple inline lists on the same page, I’m able to apply whichever layout I want to each inline list. But with list relation, this doesn’t work.
Layouts are usually linked to a sheet, so if you are using that sheet in 2 different locations in the app, changing the layout in one location will affect the layout in the other location. I can understand how it would make sense that it should work, since you are using 2 different relations, but since they go to the same sheet, then it doesn’t work. It’s kind of weird, but kind of understandable at the same time. The only thing I think that would work would be to duplicate the data into 2 separate sheets. Then each sheet would have it’s own layout.
I see. I think I understand. How is it that inline lists can be given different layouts even on the same page? I have 3 inline lists filtered 3 different ways and laid out in 3 different formats.
Is the inline list like a variable and the list relation like a pointer?
Probably because a tab that contains 2 inline lists is a detail style with it’s own layout, but when using the list relation, I suppose it’s acting like a button with a link to screen action, and since it’s going to a new screen and pulling from the same sheet, it uses the same layout. Would it be any better to use the list reference for the call list and use an inline list with the calendar layout for a meetings? Essentially the 2 layouts on the same page method.
For my specific use case it’s better to have multiple filters of meetings as list relations, which will then open in a calendar format. So I have a few list relations filtering the same meetings dataset - Scheduled meetings, Postponed, Conversion opportunities, Converted etc. The count of items in each list relation is extremely helpful, so the user know exactly how many hot leads are there for him to pursue right now.
The call list itself is secondary. I would have liked 3 cuts of data (with the count of list items showing) there also - today’s and overdue calls, upcoming calls, and fresh leads. But I can have the same 3 cuts as 3 inline lists in the layouts I want. It’s just that the inline lists won’t show the item count, and they would have to scroll a bit. I can live with that.
I would have used the list relations for the call list also, but it doesn’t really make much sense opening fresh leads in the calendar format.
Basically same issue here. I have multiple “list relations” within the same screen, but I want each one to have different layouts, but when I change the layout structure of one, it changes it on all of them.
I have the same thing. I have two different tabs that both show a different language, but whenever I change the input fields in the inline list to the fields with the other language, the lists on both tabs change! This is different than all the other elements, where I can choose the fields in the other language since they are on a different tab. Really annoying! Does anyone know a workaround?
Then there is the fact that when you want to recreate a tab, you have to do it one element at a time since you cannot copy tabs. It would soooo helpful to have these features.
Instead of two tabs, would it be easier to have one tab with one list, then have a user specify their preferred language in their user profile? Then you could add all the components for both languages and use visibility conditions to show the respective components for each language based on the selected language in the user profile.
That’s a nice idea, but it means my tabs will have the same name in both languages, which is why I created two tabs. I also wonder if I create two inline lists on one tab, whether they would both change if I make changes to one of them. I will try. Thanks for the suggestion.
I just tried. The first view of the inline list can be in the other language, but if you click through so see the list entries, they are changed in both languages if I change something. I also tried to add detail screens with lists instead of list screens, but the same.
What works now is to have two tabs (so the tab name is in the correct language) and then add fields for both languages like you suggested (with the visibility feature). The only thing is that on edit screens, Glide will give the warning that two elements are trying to write to the same column. I am not sure if this is breaking the functionality of the app, since only one language is visible at a time, so two components would never write to the same column at the same time.
Your last paragraph would have been my next suggestion, so it sounds like you are good to go there.
The warning about writing to two columns is only warning and shouldn’t be a problem. I have that same warning in some of my apps where I let the user either select from a choice component, or type in a new entry in a text component. It works just fine and shouldn’t cause any issues in your case.