I believe that a good developer will never add a relationship to a graph unless there’s no other practical way to do what s/he needs to do. Creating a relationship, by definition, creates tight coupling.
Instinctively solving programming problems in a context-independent way (loose coupling) is a matter of developing good habits. It doesn’t need to be harder, as long as you have the mental image of the appropriate design patterns in mind.
For example, a good loose coupling FileMaker scripting pattern is what we might call the “Close/Open Process Window” pattern.
Example:
Close Window [ Name: $windowname; Current file ]
New Window [ Name: $windowname; Height: $windowsize; Width: $windowsize; Top: $windowoffset ]
<do stuff>
Close Window [ Name: $windowname; Current file ]I use this pattern almost reflexively any time I need to do something context-independent, or a variant (whereby I don’t put the window off-screen and don’t issue the final Close Window) for print previews and pop-ups.
The more patterns you can internalize that support context-independence (loose coupling), the less you have to worry about it, even when (or especially when) things are down and dirty. There is a huge risk that adding a relationship to solve a problem will have unintended consequences, even if it’s just the added cognitive weight when trying to debug things or expand the system. If you think about it. There is arguably no worse time to tightly bind something than in the heat of battle. Make a habit of loose coupling in your code.
Nice tip. I am always considering the flexibility of intra-solutions and “which way” I do something might be more or less efficient for FMP to handle. Which brings me to this scenario I have been considering, and hope you could share some insight on. (BTW I’ve been working with FMP since <v3 and leapt to v6 then v11 and have retained some odd habits for good and bad and have gaps in my understanding of newer capabilities.)
My basic question is whether more fields or more TO’s are a “better” way to go.
Consider a catering type of solution with an “entree” field; choose ‘beef’ ‘chicken’ or ‘fish’. A choice is required and the choices are mutually exclusive so the field is created as a radio box of a value list and In the end I’ll need a count of each choice that was made.
A global ‘sum()’ of a conditional would be ideal, but afaik isn’t allowed, ie ‘sum(if(entree=’beef’,1,0))’ etc. – maybe a custom function? but I haven’t delved into those, yet.
alas;
I could add 3 unstored calculations based on the choice and globally sum them individually. ie field:isbeef := if(entree=’beef’,1,0) etc. sum(isbeef) etc.
or;
Create 3 global constants of ‘beef’ ‘chicken’ ‘fish’ and create 3 TO’s with relationships based on entree and count up the related records.
Maybe there is yet a better way? If not, then which is more efficient the unstored calculations or the extra TO’s? or is the custom functions straightforward enough to jump right into?
Thanks, I’m picking up some nice bits here.