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
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.
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.
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