Every FileMaker solution has common traits with regards to a typical development environment. The following Scripts are suggested for every FileMaker file. It is also suggested that you place these scripts at the very top of your Manage > Scripts dialog and not within a folder. The names of these scripts are not specific, only that they exist and can be easily identified. For example, if you prefer the name "History" vs. "Changelog" then feel free - although the names used here are suggested.
- Version
- Changelog
- Template
Version script
The version script is used to identify the current version of a file. As with plug-ins and FileMaker's own Get ( ApplicationVersion ) function, it's often critical to know which version a file is at. Being able to code logic against any given version of a file is often valuable. The method and name for the version script is not specified in these standards, however, the following script is provided as a suggestion.
Exit Script [Result: Get ( ScriptName )]
The way this script works is simple. Each time the file is revised for deployment, the name of the script itself is changed. This provides multiple advantages, any script can call this script to receive the version of the file using Get ( ScriptResult ) and it's very easy to quickly see what version the file is at when simply opening the Manage Scripts dialog.
Version number evaluation
Using a numerical result for your version function is often desired. Using the above notation which is major.minor.revision|build (see Wikipedia article on software versions) you can properly evaluate a logical test against the script result. For example, the following will result in 1.56 - GetAsNumber ( "Version 1.5.6" )
Changelog script
The Changelog script is a single point of reference to track changes made to the file. The following is the suggested method for organizing the script.
Each comment step contains the tracked changes using a readable format.
[0.1.3] - 10/10/10 - Perren Smith - Changed view order for File > Mange > Database > Tables to Custom - Changed view order for File > Manage > Security > Privilege Sets to Custom
Template script
This is simply your default template which contains your script comment header and any default scripts steps you may wish to include. This script can be used for new scripts via duplication or copy/pasting.
5 Comments
Anonymous
Matt
>> The way this script works is smiple.
john renfrew
Anonymous
"... any script can call this script to receive the version of the file using Get ( ScriptResult ) ..."
Most of the stuff in these standards is very helpful and useful, but this one is the dopiest one yet. So you can call this script and it will give back the current version? Well didn't you already know the current version when you called the script? Dopey.
I have adjusted this method so that the "changelog" returns the current version when called. Do it all in one script. One script to call.
Matt Petrowsky
When working with multiple files, file A does not inherently know what version file B is. Sure you can "see" what version it is because it's the name of the script. But you can't code logic against what you see - only what is stored or can be referenced.
Keeping the Version script separate from the Changelog is to promote clarity. Isolated functionality, wrapped within clarity makes for much cleaner code. Once you start embedding things within other things the code becomes more ambiguous (because it's buried . I know Jeremy goes even further than I have personally. He's broken out the ObjectID function into its constituent parts. Something I still need to adopt.
Suggestions are always welcome, but the fundamental premise of all code is the same. You can either have a lot of complexity that is spread wide or spread deep - either way the same logic will be required. Let's say wide would be a large number of scripts with relatively simple code and deep would be a small number of scripts with embedded complex code.
My personal preference is spreading scripts wide and having simple, straight-forward code and wrapping a good amount of organization around them.
Anonymous
My point was that I use a wrapper script always called "Version" that uses Get ( ScriptResult ) after a call to ChangeLog and loads a $$CURRENTVERSION variable (reserved name) from within the StartUp script.
I suppose that I haven't figured out how to call a script (named for the current version) if the name of the script changes for every version change.
Matt Petrowsky
I understand what you are doing. I think the confusion comes from the fact that we suggest the name of the script be the version number itself.
For clarification to anyone who ends up reading this thread. FileMaker uses internal id values to reference scripts. If your script is named 1.0.0 in file B and you later replace file B with a copy that has changed the version script name to 1.1.0 then rest assured it will be called all the same. The name of a script is not what is used by FileMaker internally.
If, however, you are using a plug-in or external technology like AppleScript then the name of the script may become more critical.
Our standards for coding suggest that you use the internal ID within your coding as well by using functions such as ObjectID which is used in best practices such as Layout references.