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 = ""
PatternCount ( SES_FND__Fund::Nickname ; SES__Session::Filter_Deals_g ) > 0
PatternCount ( SES_FND__Fund::Status ; SES__Session::Filter_Deals_g ) > 0
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.zip)
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.
Soliant Consulting employs the largest FileMaker development team in the world. We have a deep bench of talent starting with our CEO, Bob Bowers: he's co-authored seven books, led the team that has written six editions of the Authorized Training Series for FileMaker, Inc., spoken at more than a dozen FileMaker Developer Conferences, and has taught literally thousands of students spanning two decades of leadership in the field. Certified Expertise Soliant's team is certified in every version of FileMaker Pro and are specialists in building high-performance databases, hybrid web-FileMaker applications, integrations with a range of technologies including SQL, and conversions from prior versions. We work with your solution as is or can build from scratch. Find out how we can take your FileMaker databases to the next level.Website: www.soliantconsulting.com/filemaker