Advanced Portal Filtering

[picnichouse]

Hi,

I have a portal that displays all the shirts owned by a customer. I'd like to add some filtering controls above the portal display; for example, a "color dropdown" -- if the user selects "red" and presses the "filter" button, the poral will only show his red shirts.

This is easy enough when the color filter is populated, but when it is empty I want filemaker to essentially ignore the shirt color part of the relationship. Right now, if it is empty it will only display records with an empty shirt color.

This is something that would normally done through a record list outside of a portal, unfortunately we have to display a lot of data on this page so it must be in a portal.

Thanks!

Andrew

[Sanjai]

Create a second layout with a portal based on a simple relationship from customer table to shirts table (without taking the color part into consideration). When the first time user navigates to the screen, use this layout to show all the shirts owned by the customer.

Add a script on the filter button such that if the color field is empty go to the above layout else go to the layout where the portal is based on the relationship for color.

However, I would like to know that are you using a relationship using global field to populate the portal with red shirts when teh customer select red?

[picnichouse]

Here's the problem with that: There are actually something like ten different filtering attributes. Color, size, manufacturer, etc. I'd have to make a different relationship and layout for every possible combination...

Or would that still work somehow?

[Sanjai]

If there are many criteria's and choices you want to be given to the user then I would recommend use a list view layout. It would not be slower then portal. In the header of the list view layout you can put a global version of all the searchable fields example gColor, gSize etc. When the user clicks on "Filter" then run a script which would enter a find mode and copy all the global fields into the actual fields and perform find.

This would help your users to search on a multilevel criteria like show all the shirts of size 10 where color is red and manufacture is 'Arrow' and customer name is 'Albert'.

If you want to continue with portals then you may have to create multiple relationships displayed on multiple layouts.

[picnichouse]

Nope, can't do a list view layout unfortunately. Basically what I need is a way to do a one to many relationship, where if the one is empty, it returns all records. Anyone know a way to do that? Through a plugin maybe?

[LaRetta]

Hi picnichouse,

You might want to try this simple idea: In your child table, create cColorKey text calculation (index minimal) with: colorField & "¶-All-". In parent table, create a value list based upon field values and select this new calculation. You could also create custom VL if you have set values and limited number of entries. Attach this new VL to your global (gColor). In your graph, join Main::gColor to Child::cColorKey on =. Repeat with any value lists you wish to include, joining each global to each associated child calculation so your join would look like:

gColor = cColorKey

AND

gSize = cSizeKey

AND ... etc

You can get fancier ... and if you use more than a few value lists, I suggest you consider it. You would combine value list options on both sides to produce ONE multiline key - use global calc (or unstored calc) on left and only ONE 'multi VL' calc on right. User selects each VL selection (populating globals) and calculation creates the left-side key. Your child key is also created by combining several fields. This eliminates the need for a separate calc for each value list. And your join would be one field to one field, instead of multiple globals joined to multiple calcs.

LaRetta

[picnichouse]

LaRetta,

good idea, but your suggesting to key a global parent to a calculation child. It's my understanding that relationships don't work properly if the "many" is a calculated or global field.

Or does this not apply to a multipart relationship?

Am I wrong, or misunderstanding?

-Andrew

[LaRetta]

Hi Andrew,

You can use globals and calcs in relationship. What is critical is that the CHILD side be indexable. And in this case, it surely is. Give it a try ...

I use this process (actually multikey to multikey) all the time for value list manipulation. I (or someone) can provide a demo file of multikey to multikey if need be. I'll check in here when I get back late tonight.

LaRetta