FileMaker Tutorial - Selector Connector Demystified

[@jean-pierrebergeron1605]

Brillant approach guys.

[@chriswilson9269]

It seems that this is most useful when you have different layouts that use a lot of common data from other tables. The other highly useful application of this would be when you have utility table(s) that are used over and over again - however, you don't necessarily need a "selector" for this as these can be cross joined to your anchors. I think the biggest advantage is if you have a focused solution and would like to use a single layout (or a few master layouts) to drill down into your data with the use of fun things like slide panels or tab controls.

[@tomrubane3185]

Matt, thank you for this video; I found it very helpful. I'm still unsure whether I fully grasp things, though. Specifically, if you wanted a portal on the Customers layout that would display that customer's orders, it looks like you would still need to add an Orders table occurrence as a buoy to either the Customer or SelectedCustomer table occurrence. Or, is there a way to place a portal on the Customers layout that would display records from the Orders table occurrence, and have it filter the records to show only those related to the current Customer (rather than all records based on the cartesian join)?

[@DidierDaglinckx]

You'll find the links to "Selector-Connector" posts and videos from Todd Geist and Jason Young here : www.scoop.it/t/learning-filemaker?q=selector

[@KingTirto]

Thanks for the great video! Now I have a better idea about "Selector Connector". Would it be possible for you to provide the file so we can really take a good look into more details. :)

[@ysteinskuland5163]

The Todd Geist file is found here: www.geistinteractive.com/wp-content/uploads/2014/11/SelectorConnector.fmp121.zip

[@pkundu2018]

Inni

[@mrtedstein]

I am not sure I understand the benefit of this. 1) The graph may be "cleaner" but it is less informative. 2) Table occurrences are basically free. Eliminating them is a questionable goal. 3) You don't eliminate your complexity, you just move it into scripts and triggers and globals. 4) This isn't new, it just has a new name. One record interfaces with nothing but global fields aren't that different, and have been popular for a good while. 5) You lose the ability to have sophisticated relationships unless you go back to traditional TOGs. I realize the combination is possible, but at that point you lose most of the benefits of the selector/connector model. Great job on that video though, you explain it well. Thanks Matt!