{"id":9258,"date":"2015-10-07T06:10:28","date_gmt":"2015-10-07T13:10:28","guid":{"rendered":"http:\/\/www.seedcode.com\/?p=9258"},"modified":"2023-08-08T16:33:01","modified_gmt":"2023-08-08T16:33:01","slug":"filemaker-selector-connector-basics","status":"publish","type":"post","link":"https:\/\/seedcode.com\/filemaker-selector-connector-basics\/","title":{"rendered":"FileMaker Selector Connector: The Basics"},"content":{"rendered":"

Background<\/span><\/h2>\n

This post builds on the\u00a0session I presented at\u00a0DevCon 2015:\u00a0Data Modeling Beyond Anchor Buoy <\/em>which described the FileMaker Selector-Connector pattern for the relationship graph. At DevCon we also went through some sample files which are available here<\/a>.\u00a0We\u2019ll reference those files in this article as well. (You can also think of this as a continuation of my the earlier post on Selector-Connector:\u00a0“FileMaker Data Modeling with Selector Connector<\/a>“.)<\/p>\n

DevCon 2015 was an exciting time for the Selector-Connector Model as Todd Geist<\/a> won the Excellence award for both developing and formalizing the idea. I was very fortunate to have the opportunity to collaborate with Todd as the idea was developing. This collaboration lead to the current model used in our\u00a0SeedCode Complete<\/a>\u00a0template, and was the basis of my DevCon presentation.<\/span><\/p>\n

Why A New Model?<\/span><\/h2>\n
\n
\"A<\/a>
Contact Chooser (aka picker, selector)<\/figcaption><\/figure>\n<\/div>\n

On of the things I wanted to stress in my DevCon session is\u00a0that there was never an intention to come up with something new<\/em> in the abstract sense of a “model”. Todd and I both had a specific problem we wanted to solve:\u00a0we wanted to build portable choosers (aka pickers and selectors), e.g. a chooser that we could easily move from layout to layout. Not only would this make our development go\u00a0considerably faster, but in the case of SeedCode Complete, our customers would be able to take advantage of this portability as they customized and expanded the template. <\/span><\/p>\n

As it turns out, there are other benefits to the Selector-Connector that emerged, but focussing on the chooser is arguably best way to understand Selector-Connector.<\/span><\/p>\n

An Anchor Buoy Chooser<\/span><\/h2>\n

As I mentioned above, there was no intention to introduce a new data model or replace Anchor Buoy (and indeed, Selector-Connector doesn’t<\/em> replace it). Anchor Buoy (AB) has served me well since the graph was introduced in FileMaker 7, and even if I was going to bend some of the AB rules, I would do so as little as possible. With this in mind, I started developing the newest version of\u00a0SeedCode Complete using the AB model and intended to\u00a0take it as far as I could. This also had some additional practical appeal as it could lead to a clear process for \u201cretrofitting\u201d an existing AB solution with any\u00a0new benefits that emerged. What I started with very much resembled the demo file aABChooser.FMP12 <\/b>(from “Selector-Connector Example Files” here<\/a>); a basic file with Contacts, Projects and Invoices. Projects would allow for multiple project contacts, so I would build the chooser there first.<\/span><\/p>\n

\n
\"A<\/a>
Chooser In The Anchor Buoy Model<\/figcaption><\/figure>\n<\/div>\n

If we look at the graph for aABChooser.FMP12<\/b>, we see that it is still following the AB model. The table occurrences (TOs)\u00a0needed for the chooser have been added as buoys to the Projects anchor. If we wanted to maintain a strict Anchor Buoy model, then adding a chooser to Invoices would require adding duplicate versions of these TOs<\/em> to Invoices as buoys. This is, in fact, the model that the previous version of SeedCode Complete followed, and although certainly better than starting each chooser from scratch, it still required a fair amount of additional development effort for each chooser. This was as far as we could take the AB model in our goal for a truly portable chooser.<\/span><\/p>\n

A Universal Context Chooser<\/span><\/h2>\n

In the file bUCChooser.FMP12,<\/b> we\u2019ve moved our chooser TOs from being Project buoys to a new position at the top of the graph. We\u2019ve created a new table called UC; this is for Universal Context<\/b> which was the working term both Todd and I were using for “Selector-Connector” at the time. This new table would consist of one record and a few global fields for managing the chooser. All the anchors would now be related to this new table via an x-join relationship with globals on both sides. I knew I wanted to use globals,\u00a0so I didn’t\u00a0trip any downloading of indexes, and only the x-join relationship supports globals on both sides.<\/span><\/p>\n

\n
\"The<\/a>
A New Graph Model Taking Shape<\/figcaption><\/figure>\n<\/div>\n

Happily, it\u2019s very easy to make this change from aABChooser.FMP12<\/b> to bUCChooser.FMP12<\/b>. Even though we broke the relationship between Projects and the ContactChooser TO, the script references to the TO itself do not change. When we reconnected ContactChooser to Projects via the UC table, all references to ContactChooser from the Projects context remained intact. Only the global fields that were moved from Projects to the UC table needed to be \u201cre-referenced\u201d in our scripts and calculations.<\/span><\/p>\n

One of the benefits to this new model that was not planned, but soon became apparent, was that the global fields that now live in UC would have usually needed to live in the anchor tables in an AB model. By introducing the UC table, not only were we working towards a shared chooser, but we were also able to take a whole class of global utility fields out of the anchor tables and consolidate them in the new table.<\/span><\/p>\n

We now had a working chooser for Projects that should be easy to use from any additional anchor layout;\u00a0we would just need to add an x-join relationship from the new anchor to the UC TO. However, before we proceeded to hook up our other anchors we wanted to get our chooser fully functional. This meant not only being able to select<\/em> an existing Contact, but to use the chooser to create<\/em> a new Contact from within the chooser.<\/span><\/p>\n

“Pop-Back” and The Selector<\/span><\/h2>\n
\n
\"A<\/a>
The Chooser Also Needs To Create New Contacts<\/figcaption><\/figure>\n<\/div>\n

Adding the ability to create a new Contact from the chooser turned out to be remarkably easy, and this was really the point where I realized we were onto something cool. <\/span><\/p>\n

As we all know, FileMaker allows the ability to create new records through a\u00a0relationship. And any fields that are set up as match keys in the relationship force the newly created child record to inherit the values for these fields from the parent, thus making sure the relationship remains valid after the new record is created. However, less well known is what happens if the parent value for one of the match fields is empty. If the child field is set to auto-enter a value, then that value will be \u201cpopped back\u201d to the parent record. Presumably this is FileMaker\u2019s attempt to maintain the relationship after the creation of the child record. \u201cPop-Back\u201d is the term I learned for this behavior. Our friend Kevin Frank<\/a> refers to it as the \u201cMagic Key\u201d which I’ve also always liked.<\/span><\/p>\n

For our creating new Contacts\u00a0in our chooser, this behavior works perfectly. If we want to create a new record, we just need to add a new global field to the UC table and then add a creation relationship to Contacts with the global field and the Contact\u2019s primary key (shown below). We then need to make sure our global is empty and expose the fields from\u00a0this new relationship in our selector (editable fields like FirstName, LastName, etc.). As soon as the user types into these fields, the new record is created and the primary key value is popped back to the global.<\/span><\/p>\n

Although there\u2019s no editing involved with our chooser, it was clear that this relationship could also be used for editing an existing record from any context as well. Rather than clearing the global field, we’d\u00a0<\/span>set it to the primary key of an existing record we wanted to edit. This is where the language and term for the \u201cSelector\u201d started to take form, and Todd deserves the credit for clarifying the naming pattern. The central table with the global fields becomes the Selector. This name fits well because it\u2019s the globals in this table occurrence that you manipulate to form a relationship with the \u201cSelected\u201d record. The table occurrences to the right become the Selected, i.e. SelectedContact. With this naming convention, the workflow becomes very clear:<\/span><\/p>\n