Basic Portal Filtering

[mr_vodka]

This is a very basic demo for portal filtering including an "All" option for those that have asked backchannel.

* Edit - made a modification to file.

Portal_Filter_Basic.zip

[swl]

John, Thanks for posting this FilteredPortal demo. I knew it was simple but I couldn't get mine to work and found this helpful to finally fix my issue.

[John Cleary]

Hi John,

 

Thanks so much for this sample file! Very helpful!

 

Just wondering, could this method work to filter the portal by two different variables? I haven't quite unpacked exactly how it all works, but say if I wanted to be able to filter by both "Type = Bonus" and optionally ALSO say "Amt > 100". Would that be possible?

 

Thanks!!

John

[mr_vodka]

Yes. You can filter by multiple criteria.

[db_tragic]

Hi mr_vodka,

 

Just trying to understand the components of your example.

 

I gather the 3 scripts are aimed at resetting the sort filter criteria to "All" in each of the 3 different scenarios during navigation.

 

The sort filter calculation applied to the portal:

Parent::gSelect = "All" or Parent::gSelect = Child_FMP11::Type

 

….is the one I don't quite get, presuming this is what the portal uses to determine what the sort filter criteria are (based on the gSelect value).

 

Would you mind elaborating on how this calculation works to produce a sort filter for anything other than  an "All" value in gSelect.

 

TIA

Edit: Changed 'sort' for Filter ("Filter" was always my question, brain locked onto 'sort' - doh! - Thanks BruceR) 

 

 

This is a very basic demo for portal filtering including an "All" option for those that have asked backchannel.



* Edit - made a modification to file.

[bruceR]

It isn't a sort.

 

It's a filter.

 

For every record in the relationship defined for the portal; only display the record if its TYPE = gSelect

[db_tragic]

Thanks BruceR,

 

Corrected my sloppiness - was always thinking filter!

 

As for the calculation, in my limited experience, I haven't come across one set out like that before;

 

Is that similar in function to an "If….Else" calculation? Could such an expression be used instead here?

 

 

It isn't a sort.

 

It's a filter.

 

For every record in the relationship defined for the portal; only display the record if its TYPE = gSelect

[comment]

Is that similar in function to an "If….Else" calculation?

 

The If() function has this structure:

If ( test ; result1 ; result2 )

The test expression is evaluated first for being true or false, then the appropriate result is calculated and returned.

 

 

When filtering a portal, you only need to supply the test expression: if it evaluates to true, the record is shown, otherwise it's not. IOW, filtering a portal by =

Parent::gType = Child::Type

is equivalent to saying:

 

If ( Parent::gType = Child::Type ; show this record ; do not show it )

[db_tragic]

 

The test expression is evaluated first for being true or false, then the appropriate result is calculated and returned…….

 

 

When filtering a portal, you only need to supply the test expression: if it evaluates to true, the record is shown, otherwise it's not. IOW, filtering a portal by =……..

 

Thanks for your post Comment - love your work!

 

OK bear with me on this……..

 

I now understand the second part of the expression in the calculation:

 

Parent::gSelect = Child_FMP11::Type

 

​……..will only show those records in the portal whose field Child_FMP11::Type matches the currently selected value of Parent::gSelect.

 

The first 'test' in the equation;

 

Parent::gSelect = "All" 

 

​……I don't understand just yet. It looks like it's just trying to match the Parent::gSelect field with the string "All", and not compare it to the content of another field, as in the second part of the equation (which then defined the filter). Or is this expression effectively saying, "if the value in the field Parent::gSelect is equal to 'All', then the expression is true, and as no other field-based filter is specified, then all records are shown?

 

The next component I need to clarify is 'or'.

 

Does this operator become engaged by the calculation only when the preceding test returns a 'false'? (I haven't used 'or' in calculations before, so be gentle!) If so, does that mean that it's possible for several 'or' operators to follow each other within a single calculation, based on the notion of "if this test is false, go to the next expression in the calculation…….and if that test proves false, go to the next expression….etc..(where each test is separated by an 'or' operator).

 

TIA

[comment]

"if the value in the field Parent::gSelect is equal to 'All', then the expression is true, and as no other field-based filter is specified, then all records are shown?

 

Yes, that's exactly how it works. There is no rule that the test must examine some attribute of the child record (though usually that is the case). Of course, when it doesn't, the result will be applied to all child records without exception - which is the intended outcome in this example.

 

 

 

does that mean that it's possible for several 'or' operators to follow each other within a single calculation, based on the notion of "if this test is false, go to the next expression in the calculation……

 

Yes. I am not sure about the exact order of evaluation (though I believe it's from left to right, just as you described). The gist of it is that if at least one of the conditions returns true, the entire expression is true. IOW, all conditions must return false in order for the expression to return false.

 

See also:

http://www.filemaker.com/13help/en/html/non_toc.46.40.html#1029464

[db_tragic]

Thankyou comment for your help clarifying this. Much appreciated as always.

 

 

 

 

Yes, that's exactly how it works. There is no rule that the test must examine some attribute of the child record (though usually that is the case). Of course, when it doesn't, the result will be applied to all child records without exception - which is the intended outcome in this example.

 

 

 

 

Yes. I am not sure about the exact order of evaluation (though I believe it's from left to right, just as you described). The gist of it is that if at least one of the conditions returns true, the entire expression is true. IOW, all conditions must return false in order for the expression to return false.

 

See also:

http://www.filemaker.com/13help/en/html/non_toc.46.40.html#1029464

[db_tragic]

To take portal filtering a step further;

 

The scenario I'd be using this would be to display a portal containing client invoices. In the supplied example, my filters here would be "All", "Balance = 0.00", "Balance > 0.00" - I've got that part figured now.

 

In addition though, I want to be able to (optionally) filter the invoices by date range - either on the 'unfiltered' invoice list, or when it is filtered.

 

I imagine the date filtering would be set up as a separate function, so that the user first sets the date range (if they in fact need to, i.e. is an optional filter), and then selects from a drop-down list (as in the supplied example) to filter for invoice balances.

 

If I've applied a date range filter, will the balance filter only filter the found records from the date filter, or will it override this, and perform the filter on all records, effectively cancelling the date range filter?

 

 

 

 

Yes. I am not sure about the exact order of evaluation (though I believe it's from left to right, just as you described). The gist of it is that if at least one of the conditions returns true, the entire expression is true. IOW, all conditions must return false in order for the expression to return false.

 

 

[comment]

I'd suggest you open up a new thread with this question. as this is no longer a follow-up on John's demo.

[db_tragic]

Will do. I'll trawl through the forum first in case there's info on it -  was just on a roll!

 

 

I'd suggest you open up a new thread with this question. as this is no longer a follow-up on John's demo.

[carlosnorvik]

Hi:

Thanks, this simplified my filtering, before I had a Case(...) and had added a field to the child table which entered a 0 value upon creation of a new record; therefore my formula was if empty  cero field in child =0 (showed all) if not empty match name (showed one).

I used your formula and changed the "All" to "" (empty) and it works fine. It is a contacts database and filtering displays only the desired contact. Velue list of persons shows only related names.

I have 2 unsolved problems now:

a)Timestamp, when I enter a name to filter, I update parent so I no longer info. on when some "fixed" data was modified. It could be solved by adding an extra table with just 2 fields (Company Nick Name and person to look up). Company Nick Name handles relationships (and it is not easy to change it and ruin the relationships).

2) Cleaning the person to look up in the parent table upon exiting the record, so that the next person who sees the record finds a full list of persons. It can be done via a button but I would love to find a script trigger to do it  

 

[comment]

With regard to the first problem: you should be using a global field (on the parent side) for the filtering expression. This will not only prevent the parent record being modified, but - much more importantly - enable two users to apply different filters without obstructing each other.

I wasn't able to understand the second problem.

 

 

Edited December 7, 2015 by comment

[carlosnorvik]

Hi Comment:

I changed the field to global on the parent side and filtering stopped working.

Changed it back to text field and it started working again.

I must be doing something wrong.

Suggestions are very welcome

Thanks

Carlos

 

[comment]

1 hour ago, carlosnorvik said:

I must be doing something wrong.

I suggest you compare your implementation with the demo file in the opening post of this thread. You will see that the filtering expression is entered into a global field (gSelect).