I had the opportunity to play with filtered portals yesterday! (I split my time between Salesforce and FileMaker, and it’s been a while since I’ve had a project where I get to play with these. Please pardon my enthusiasm, but this is FUN.)
I needed to set up a dynamic filter using a global field, and decided to try incorporating it into the portal filter definition rather than proceed as I normally would and incorporate the global into my relationship.
I’m pleased as punch with the result. I now have a tiny script called via trigger, and can bop-bop-bop around the solution and apply these dynamic filters to all of the portals on all of the dashboards the user has requested without touching my relationship graph.
Here’s a simple shot of what I want:
The user can type anything they want into the Filter field, and the system will match on any part of any word on any field in the results in the portal. (Instantly and without effort, of course.)
Idea 1: stick the filter logic into the portal definition. Easy enough! Here’s what that looks like:
…and the logic, allowing for the filter to be empty as well:
SES__Session::Filter_Deals_g = "" or PatternCount ( SES_FND__Fund::Nickname ; SES__Session::Filter_Deals_g ) > 0 or PatternCount ( SES_FND__Fund::Status ; SES__Session::Filter_Deals_g ) > 0 or PatternCount ( SES_FND__Fund::Rating ; SES__Session::Filter_Deals_g ) > 0
But it wasn’t instant. Or frankly responsive in any way.
A quick Google and the FileMaker community reminded me that I need to flush the cache. (Thanks, fmforums.com!) (And perhaps I shouldn’t code in the middle of the night.)
On my way to that answer, I came across another great tip from a commenter on filemakerinspirations.com: using Set Field to set a field within the portal to itself — rather than Refresh Window (flush joined cache results) — will reduce screen-flash for our PC-using friends.
I have to confess that PC users are more of an afterthought for me because I’m evidently a self-centered, self-indulgent Mac user. So I’m pleased when I can incorporate something for them pre-emptively rather than reactively.
So, the simple script, in English:
- Commit Records (so the changes the user makes to the global are recorded)
- Set a field in the portal to itself (shortcut to essentially refresh the cache)
- Go back to the filter field so the user doesn’t notice the system doing anything
Because I’m going to be applying this all over the place, though, I needed to abstract it a bit. With the help of a nothing-fancy custom function to parse my parameters (which you can check out in the attached sample file), here’s the final script:
Here’s the sample file if you want to see it in action: FilteredPortals.fmp12
I admit that setting the $param variable is unnecessary, but I get itchy if I type “Get (scriptParameter)” more than once, so setting that variable is a little reflexive at this point.
And yes, the script comments are longer than the script itself. That’s how simple it is!
Other keys: if you abstract the script like I did, remember to give an object name to the global filter so you can pass it into the script and navigate back to it after refreshing the portal.
- Will filter based on any part of the word (or phone number)
- Super-simple to implement across the solution
I’ll need to see what the performance is like. It’s acceptable for me now over a remote connection a couple states away, but our nascent file has all of 10 records in it. Filemakerinspirations.com has some tips on (legal) performance enhancement, so I may be testing those out next. (I like the idea of using an OnTimer script to delay the “instant” calculation until fast typers have paused for .3 seconds.)