Perform Script [ by Name: ... ] - immediately + natively (Modular-FileMaker)

Idea created by mrwatson-gbs on Oct 29, 2015






    My idea is an extension to the existing Perform Script step, which makes it possible to


    • Perform scripts by Name ...
    • that is, WITHOUT putting the script onto the script stack for later execution, as similar plugin functions do





    The Perform Script step should have



    • a checkbox: [X] Perform Script by name
    • a field for a calculation where the target script name or calculation can be typed
    • a specify button to open the calculation editor


    See the pic --->

    Perform Script by Name 1.png




    It should work something like this:


    1. If the Perform Script by Name checkbox is unchecked,
      • the Perform Script script step functions exactly as before, i.e. it is 100% backwards compatible!
      • In the script workspace the script step thus appears the same as ever:
        • PerformScript ["MyScript"]
    2. If the Perform Script by Name checkbox is checked, and a calculation is entered:
      • if a script was previously selected in the script list, it is deselected.
        • In this case the script list could be greyed out or possibly even hidden.
      • At runtime the target script name is calculated and used to find and perform the target script
        • If the resulting string is empty, no script is performed and an error 104 (Script Missing) is returned.
        • if the calculation is invalid and returns a (NaN) '?' token, this should be converted to a string "?" and script "?" should be immediately performed if present.
        • if a script with the calculated target script name exists (i.e. case-insensitive comparison) in the target file it is immediately performed, as normal.
        • otherwise an error 104 (Script Missing) is returned.
      • In the script workspace the script step appears something like this:
        • PerformScript [by Name: "MyScript"]
    3. If the Perform Script by Name checkbox is checked, a script is selected, but no calculation is entered,
      • the name of the selected script will be used to find the target script at run time.
      • both the name and internal ID of the selected script are stored in the script step.
        • Note: Because in this scenario the internal ID of the selected script is also stored, the run-time behavior can be optimized to first check the script with the stored id, and only to search for the target script by name if the name differs.
      • This form would have to be visually distinguished from case 2, e.g.:
        • The stored name could appear as a grey default in the calculation field,
        • In the Script workspace the script step appears something like this:
          • PerformScript [by Name: ["MyScript"]]
      • Moreover, if after returning to the script step the selected script (having the stored script-Id) now has a different name, it must be clear that the selected script WILL NOT BE RUN
        • Details needs to be thought through.
    4. Renaming a script
      • causes future Perform Script by Name calls to break and return an error.
      • One could consider, whether a refresh option for case 3 could be useful



    Why this idea is important (to me, to you, to everyone)


    Performing scripts is at the heart of any database. We can currently Perform Scripts by name using plugins. This has several major drawbacks.


    1. You need a plugin
    2. You cannot control WHEN the script will be run
    3. the context (time, place, layout, record) may have changed (e.g. if your script is looping over records/changing layouts, then the script may be performed on completely the wrong record / from a different TO)


    Thus the benefits of this suggestion:


    • This is the central function required to Make FileMaker more modular
    • It will increase the power of the FileMaker platform,...
    • It will make programming API-interfaces between files hugely simpler and straight forward.
      • Files can provide an API (Application Programming Interface), in the form of a list of named scripts, which other files can simply call, without having to worry about internal IDs or execution timing
    • It will vastly increase the availability of modularized building blocks in the FileMaker world
      • Standard APIs can be published among FileMaker developers; each developer can build the scripts into his/her solution, and any other solution will then be able to call the scripts of the API by name
    • It will reduce errors, boost productivity and aide deployment
      • Script calls won't break due to having different IDs in different databases
      • It is simple enough for young developers to use, develop and support
      • Scripts are always performed in the same context as the calling script
    • Even within single files it will provide benefits, for example
      • it would make it possible to implement the equivalent of a switch/case control structure as a flexible and efficient alternative to huge if ... else if ... constructs.(See use cases below)



    Specific use cases you are looking to solve


    1. Task Scheduler


    We have a module in our solution which performs scheduled actions based on task-records in the database.


    This is already programmed successfully using plugins, but suffers from the stack-oriented call method, which makes the system complicated & difficult for non-experts to develop + support.


    Perform Script by Name would make this kind of application completely straightforward & obvious to programme in a naturally FileMaker way.


    2. Programming new functionality across different versions


    Sometimes we develop super  new functions in the master version of our database, that our existing customers also want built into their old version of the database. These functions are nearly always spread across multiple files, with core functionality is often added to our main file ( Advanter). Calling Scripts in external files is typically very common in such functions.


    The existing Perform Script [by internal Script-ID] step is found to be extremely wanting


    3. A flexible and efficient case/switch control structure


    We have - as all FM-developers have - many scripts with long if ... else if ...else if ...constructs, which function like switch/case constructs of other languages. This could be shortened to


    Script "Go to Module"

    Perform Script [by Name: Get( Scriptname ) & " " & Get( ScriptParameter )]


    Script "Go to Module Books"

         # Code for Book Module

    Script "Go to Module People"

    Script "Go to Module Returns"



    4. Parsers


    Being able to perform scripts by name will make it possible to write text or XML parsers, where the recognized tokens cause scripts to be performed.


    5. Implementation of a data-driven testing environment


    Tests can be defined in records and then sequentially executed


    6. Object oriented functionality / Setters + Getters


    Performing Scripts by Name is a key component on the way to creating object oriented functionality.


    For example, a (simplified) Getter Script :


    Script Get ( Property )


    Set Variable[ $Property ; GetValue( Get( ScriptParameter ) ; 1 )]

    Set Variable[ $Script ; “Get” & $Property]


    If ( not isempty( ScriptNames( Get( FileName ) ) ; $Script )]

       # Use Getter script

       Perform Script[By Name: $Script]

       Exit Script[ Get( ScriptResult )]


       # Read field

       Exit Script[ GetField( $Property )  ]

    End If


    7....etc., etc., etc., ...


    If you want this feature - and believe me you do, you REALLY do! -

    please vote it up, like it, share it, bookmark it, tweet it, blog it,

    tell your friends and colleagues,

    get it got!




    I particularly invite everybody to contribute to the list of use cases in the comments below.


    Looking forward to really modular FileMaking