Updated 11/24/2014 ( see below for whats changed )
Update 2/24/15 – Jason Young wrote a great blog post about using Selector Connector with Seedcode Complete.
Wasn’t this called Universal Context?
This is a video of what was the Universal Context presentation I gave at Pause on Error last month. The name however, had to go. It turns out that a “universal context” is only one of the features that kind of falls out of this graph architecture. So we busted one model into two and came up with a “Selector Model” and a “Connector Model”. I hope to put up something more definitive in the future, but I wanted to get this out quickly, because many nice people asked me to. 🙂
What Problem Does it Solve?
We started down this road to be able to make our complex solution simpler by building re-usable components. We didn’t want the graph sprawl that comes from having extra instances of TOs, and we didn’t want our scripts to get ridiculously complex because they need to handle different contexts. That was the aim of centralizing context. We wanted to write relatively simple code that worked from as many contexts as possible without causing undue graph sprawl.
Selector Connector does a pretty good job of meeting those goals. The really surprising thing for us was how simple some things got. 🙂
FileMaker Selector Connector Model
I am going to give a brief outline. For more detail, watch the video, or check out the example file below. For starters, these models are focused on how you build graphs for UI and scripting. Data level graphs might very well live in a different file if you are doing data separation. You could certainly build your data level relationships with this model. It’s just not what you’ll hear us focusing on.
There are really two separate concepts here. The fist one is the use of a single record, globals only Table/TO called “CONNECTOR” to connect everything together with cross join relationships. This is what creates the universal-ish context. The cross join makes it so your main table kind of share a context. Once you have that in place, a lot of stuff gets simpler. In the movie, I demonstrate several features that get rather simple once you put the “Connector” in place.
The second concept or pattern is the “Selector”. I know, it comes first in the name, “Selector Connector”, but that’s just because it sounds better than “Connector Selector” :-). It is a separate idea and could be used alone or in combination with a Session model quite well.
The “Selector” makes things Selectable. You “Select” records by setting global fields in the SELECTOR table occurrence. Those field are used are used as keys in relationships to each of the main tables in your system. If you want to select a customer record, you would use a set Set Field Step to set the “SELECTOR::_id_customer” field. (See how nice that reads?) That gives you access to that record through the “selected_Customer” TO. You can also use the Selector Model to create, edit, and even delete records.
FileMaker Relationship Graph Organization
In the end it all comes down to how you connect your Table Occurrences. Take a look at the image below. The CONNECTOR TO is on the left and the “SELECTOR” is directly to its right. The TOs outlined in yellow are where you build your Layouts. Up top in orange; those are utility tables. Notice how CONNECTOR is connected to all the other key TOs with an cross join. Thats the key. (You can click on the image to zoom in.)
I’ll admit that at first I was wary of connecting everything together with the CONNECTOR. But once I did it, it became increasingly clear that it made a lot of things simpler. Things like graphic resource TOs, dynamic flexible navigation systems, Virtual Lists, pickers, and even DB Transactions just get easier. In the video I cover a lot of what gets easier in detail.
Whats the Catch?
So far we haven’t found any major problems. You will need to refresh the cross joins occasionally, much like you might have to refresh a window or an object sometimes. There is a script called, “Refresh xJoin” in the sample file that does the refresh for you. You also have to get used to seeing all the TOs being in one long list in some of the relationship selectors where they would otherwise be broken up into related and unrelated groups. This doesn’t bother me as it always showed up as one long list in scripts anyway.
At first it might seem like you end up with more TOs. than with other architectures. But some of these TOS are utility low record count Tables. Those are pretty cheap, and you only need one instance of each one, since it is connected to everything through CONNECTOR. Also regular data TOs will get re-used more effectively. For example you only need one selected_Customer TO for the whole graph. I think that in a complex system you will have less TOs in the long run.
11/24/2014 – fixed some errors and added comments to the “Refresh xJoin” script. This is a critical script so it is worth checking out.
Please understand this is a demo file. The code here has been pulled out of customer code that we couldn’t share. Expect bugs and problems. But the key concepts should all be there.
Please let us now what you think. 🙂