Enhancing the Interface With Filtered Portals

Recently, I’ve heard some push back when it comes to using filtered portals in solutions. The reason? Filtered portals are slow for large data sets. And this is a fair point. However, filtered portals and I have a close bond for reasons beyond their Brita-like tendencies of leaving the good and filtering out the unwanted. I love using filtered portals because they can enhance the interface, while providing flexibility for the developer.

Recently, a customer wanted to streamline a process and I decided to implement a checklist to get this done. Of course a simple checklist isn’t enough, as each step that uses the system should be clickable so that the user is taken to the right place to complete the necessary action. In the past, how would I have accomplished this?

Two Solutions

I can think of two solutions:

1. A slew of text boxes with scripts attached to each
2. A portal to a table that shows me the task and description with a rank field to sort them correctly

So before the birth of filtered portals, I could have accomplished what I want with #2 above. So why the admiration for the filtered portal? The filtering capability means I can use one table to house different checklists, and when I go to apply a portal with a new filter calculation to a new layout, a little copy/paste and I’m nearly done. All that’s left to do is change the calculation for the filtered portal. In pre-FileMaker 11, I would have created a different relationship for each type of checklist. Less table occurrences makes for a happier developer!

In the example of my customer, there are two different types of checklists: the input and the output. The input is all about how they enter the data. The output is all the “printables” – invoices, project details, project summary, etc.

Setting Up a Filtered Portal

Let’s talk technical – here are the fields I setup in my checklist table:

• Type – identifies different checklists
• Description – what the user sees
• Parameter – what the script will use to perform the correct action and take the user to the right place
• Rank – what the portal uses to correctly sort the checklist

How are my portals filtered? By the field “type.” An example would be as follows:

data_checklist::Type = "Input"

Nice and simple, right? Let’s kick it up a notch, á la Emeril Lagasse.

Imagine if you had an Issues database. What if a list of suggested questions or actions were provided, based on the scenario? Instead of hard coding the actual type, you can reference a field in your table:

data_checklist::type = data::category

Conclusion

So let’s step out of the proverbial box and into the world of possibilities – I’ve used filtered portals more for interface enhancement than for true data filtering, but what’s the harm in that? In fact, using filtered portals in this form helps the developer in adding flexibility via relationships and scripts. By abstracting the interface into a relationship and filtered portals, often modifying the interface can be as simple as adding a new record in a table.

Want to see these techniques in action? Check out my sample file! I’m using the table “Checklist” for the filtered portals in both examples.