Watching some threads and good Robert Petitto’s videos about creating customized filters using an Inline List component, I thought an idea to make it simpler and avoid configuring manually the Inline List’s filter and suddenly, I got this to share :
The trick is to work with a multiple relation base on values (filters) selected by user which will rule your Inline List data and as you can see, you don’t need to configure/create internal filters later.
I like what you’ve done with the template/split text combination.
Although I’ve been creating these types of dynamic relations for quite some time, it’s always been a combination of template + if-then-else. The split text approach never occurred to me, but having seen what you did here I think it’s a better (cleaner) approach. Nice work
Glad to see my solution gives new ideas to other situations.
Another advantage with it is that you can have quickly the amount of records the filters bring back due to it is working with a relation. Any Rollup pointing to this relation will give you the amount.
I think @kyleheney was looking for something like it weeks ago.
My original idea was to create a kind of “SQL Query” inside Glide although the big troubles came from playing/working with parameters using an OR operator and AND operator at the same time (a hard challenge sometimes in GDE).
In the end, a Filter is almost a SQL Query when you try to narrow your useful data.
When I ended this idea, I evaluated if this had been a good solution ( a clever idea) or on the contrary, it might create more load/work for Glide (unnecessarily) due to use of template columns changing dynamically along with relations based on them.
To sum up: the endless dilemma between Efficiency vs. Effectiveness when our APP is using this method with a large amount of data: 15k or 20k+ rows
I don’t know at the end whether the best option is to load all data once and let Glide filter and discard values/rows automatically or create/use a dynamic relation to get a specific result always (my idea). Which process is better for Glide? … I don’t know yet
I read @Darren_Murphy and @Jeff_Hager discuss about this issue here and I agree with some points but I think the friends @Mark or @Jason can give us the final answer to have the best performance on our APPs always.
In my experience, filtering any list (whether by condition>relation>inline list OR inline list>condition>filter) is considerably laggy when that condition is built off of an earlier rollup of a datetime.
For example:
Log of categories and dates > relation to self of log categories > rollup of earliest date > if rollup is date then true >filter inline list where if = true.
Question is, in this instance you only have one row with compute columns and then the relation is built on top of them -
Perhaps as it is a single row it uses significantly less resources than if it were lots of rows -
In which case the conventional way of looking at it doesn’t apply.
Also wondering whether lots of users using a user specific column then having compute columns like template on top of them (and then a relation) -
How many users Glide can handle
To me, it’s the best way to do this kind of operations and avoid affecting other columns/tables by accident. I just try to use/put a relation where there is no much data (or few columns) involved or associated to that relation and “help” Glide a bit during the table updating.
The assumption is very sound,
The question is whether it’s true, especially with multiple compute columns.
But since it’s only a single row with user specific compute - and it doesn’t compute the bulk of the data - only this row and pulling the relation columns accordingly - perhaps it can handle much much more -
I was thinking maybe start using this method always.
Instead of having users entering actual screens, just go virtual, like this method.
For instance I Have projects, in this project I have multiple related Tables; “Openings”, “Types”, “Records”
Instead of Going into a detail screen of the project and pulling up the related Inline lists, I would just have a virtual screen which pulls up the inline lists -
Therefore I won’t have to build Template/compute columns and relations directly within these Tables which are rather large
:
