Method needed to Define & Document Multiple Script Parameters & free up Script Name

Idea created by mrwatson-gbs on Apr 4, 2016

    This idea has developed out of the discussion about Native Multiple Parameter Passing.


    The problem with documenting Script Parameters in the Script Name


    Due to the lack of an extra mechanism for documenting script parameters, there is a widespread convention to document parameters within script names themselves. While this greatly helps current developers to correctly pass long lists of parameters to scripts, by providing the necessary hints within the script name, it has the massive disadvantage of making the script name temporally unstable:


    - The parameters of a function tend to change over time, as new aspects of a scripts function develop. Somewhere between occasionally and frequently.

    - On the other hand the function of a script tends NEVER to change.


    This situation means that a great idea like Perform Script [by Name:...] - immediately + natively (Modular-FileMaker) or external calls via the fmp URL protocol or using a REST API are doomed to be unreliable and regularly break every time a script parameter changes.


    This is not good.




    • Script names need to become a stable description of the script function.
    • It is fundamentally important that FileMaker provide a separate means of documenting parameters, so that script names can be freed up to document ONLY the function of the script - permanently and stably!
    • It must be possible to see, call up or automatically insert a list of script parameters in the Perform Script dialog.
    • Similarly it should be equally simple to see, call up or automatically insert the list of script result parameters.
    • It must be possible to add optional parameters to scripts which do not break existing calls


    In this way Perform Script [ By Name: ... ] could become an extremely powerful building block in Modular FileMaker solutions.




    • Calling script by name (whether by current plugin-methods or future native methods) becomes more usable and reliable
    • Improved maintainability, because script-calls break less often
    • Improved integration of FileMaker Databases (paves the way for a stable external REST API)
    • Script names will be more descriptive/less cryptic, since all 100 characters are available


    Use Cases



    While very closely related to the idea of Native Multiple Parameter Passing I feel this idea merits a separate entry.


    Exactly HOW parameters should be defined and documented I leave open to discussion and development within this thread. I first of all wanted to focus on the need to free up the script name.


    Your ball.