Web Direct is becoming increasingly popular with FileMaker developers as it is easy to implement and in many cases, faster than FileMaker client pulling data from FileMaker Server.
There are many examples of how to do dynamic portal filtering which are highly effective using the FileMaker client software, but don’t work so nicely in a Web Direct solution. This is caused by a Script Trigger on the “Filter” field which commits the record, thus updating the portal. In a Web Direct Solution, if you enter characters into the field faster than ~ 15 WPM, you’ll get lag and your characters can be entered out of order.
Here is my solution:
Now, this script is used with a custom function – which I did not write – called
“IndexWord” which takes two arguments, ( Text, Header ) where Text is the word you want to call the function on and Header is just “” – double quotes.
tCount = Length(Text);
newHeader = If(Header ≠ “” ; Header & ¶ );
NewText = Left(Text;tCount – 1)
Text = “” and Header = “”; “”;
tCount = 0; Header;
IndexWord(newText ; NewHeader & Text)
This script recursively breaks down all the letters in a String so that IndexString(“Noah Harris”; “”) becomes:
Now, obviously this is only so helpful. If you want to be able to use this in a dynamic filtering kind of a way, you need to create some fields and relate them. Lets use a Person table as an example.
Naturally, you’d already have fields for the name_first and name_last and probably the two calc fields name_wholeFL and name_wholeLF. For dynamic filtering, lets add two more: Person::g_search and Person::nameSearch. Now, g_search is just a blank global field, but nameSearch is a calc field equal to
IndexString(name_wholeFL; “”) & ¶ & IndexString(name_wholeLF; “”)
This gives you the breakdown of the first and last names, along with being able to search “Noah H” or “Harris N” and still be able to find my record.
Below is the relationship for setting up the filter.
So If you’re a on a Layout based in Person, with a portal looking at Person~DynamicFilter, by typing into the g_search field – in this case, the one above the portal – you’ll automatically filter the portal.
Now, if you’ve been following along so far, you may realize something is off with the last step. If you modify the relationship graph to look as follows:
you can put two portals, one from each branching Table Occurrence, on top of one another, and set hidden conditions on them.
The reason for two portals is so that when the search field is blank, it’ll allow you to display all the records in the table from Person_PER – this, of course, can be sorted however you like. I usually opt to sort based on name_last.
The hidden conditions are pretty simple, for the portal looking at ~DynamicFilter, just set the hidden condition to
Person::g_search = “”
and on the portal for Person_PER to
Person::g_search <> “”
If the portals are lined up and on top of one another, then it’ll look very flashy!
Feel free to ask questions!