There are some things that are easier to explain through examples. Putting the Set Field By Name script step to work is definitely one of them. It’s not a complicated process, but seeing the new [Indirection][ind] capabilities that Filemaker 10 has to offer makes a much stronger impression than trying to talk through it. Also, all my introductory quips for “isolating” and “isolation” were turning out quite depressing. So, here is how we used to find a specific record, and how we can do it now.
[ind]: /wp/set-field-by-name-exposed/ “Indirection SFR Style”
##The Old Way
For this article I’m going to assume you are using two methods that are a part of our development process. The first is [multiple parameter passing][mpp] (feel free to check this out if you’ve never run into it before) and the second is Safe Find. Safe Find is a script we use to safely run a find and capture any errors that occur and return them without throwing an error dialog. Here is a copy of the actual script:
So, now on to the concept of Indirection. Here is how we used to find customers using our standard naming conventions, parameter passing and error handling:
Now, here is how we find orders:
And now for something completely different. Here is how we find vendors:
By now you’re probably seeing a trend in our scripting that has driven me nuts since day one. In Filemaker 9, we had to maintain a separate set of scripts for each context that we wanted to operate in. If we want to find a Vendor, that’s one script. Find an Order? That’s a second script. Customer? A Third script.
##The New Way
Here is how we can find a Customer, Order or Vendor now:
This little beauty does something that makes us here at Six Fried Rice absolutely giddy. I can call it from any layout, pass it an ID and it will isolate the record with the corresponding ID without any further hassle! It is completely context independent. Essentially we now have a single script to replace every find by ID script we have ever created. A huge part of development model revolves around using structures, systems and conventions to centralize and simplify the development process. This particular script is a perfect example of a very simple application of a very useful feature to cut out a huge amount of redundancy in a systems.
Note: This script does require that a few things are in place before hand. For one,
you’ll notice that we use the Set Field By Name to set “ID” to the parameter that is
passed in. This only works if you strictly follow the naming convention that dictates
having a primary key field called “ID” in every table. I’ll be posting an article going much
deeper into our own conventions, but for now remember that to use a script like this, you
*must* have consistent naming conventions throughout your system or the script will not
execute correctly.
[mpp]: /wp/passing-multiple-parameters-to-scripts-advanced/ “Multiple Parameter Passing”
Of course, you can also just add another parameter like so: [ fieldName ; id ]
Now your script parameter would look like:
PassParameter( “fieldName” ; GetFieldName ( TO::Field ) ) &
PassParameter( “id” ; “1234” )
Now you can isolate any field, not just your primary key fields.
– Dave
David,
That is a great point. Anytime a script is completely generalized I am a big fan, and your method certainly does allow for that. As a completely minor not though, with that scenario I would pass in the parameters “FieldName” and “Value”, just for semantic reasons. Aside from that, this exactly how the script should be written.
@Daniel: But of course. Good catch. 😉
even if it makes no sense for a find, a SetFieldByName generic script should also have a ‘repetition’ parameter (you never know…) 🙂
I have been using programmed indirection for some time to allow for generic routines such as the one you suggested above. This has saved an enormous amount of coding and allows sophisticated generic routines to be written *and* upgraded as the change is one place. The trouble is that the low level scripts which do the generic field setting are slow to execute when you have (as we do) large numbers of tables because of the share volume of if elseif statements to traverse. Now with Set Field By Name, those low level routines are (in most cases) no longer needed and the performance will be compiled code speed instead of script speed (huge difference of course). Field indirection is a huge feature.
And to extrapolate a little more, you could take a list of params as name/value pairs, loop through the list with a set field by calc for each one. This would allow for multi-field finds.
To take it one step further there could be a third section to each name/value set for ‘Find’ or ‘Omit’.
To take it one step further ….
Ahh, the new found joy!
Karstyn:
Keep your eyes peeled. Jesse has been working on just such a thing (plus a few extra fancies). Should be very cool.
Geoff
Interesting problem – tried the code and it failed to work! Problem was with the field name. Change the calc to:
set Field By Name [Get ( LayoutTableName ) & “::id”; #P(“id”)]
and worked as advertised. Is this a change to FileMaker 10v3 or somethign else?
@Fabrice – wouldn’t it not matter what repetition of you search in a field? I thought searching a repetition field will pull values from any repetition.