External References need to be more modular/looser:
- It should be possible to refer to a file that may or may not be present WITHOUT FileMaker presenting the user with an error message or an open file dialog (maybe an [X] Optional reference checkbox in the External Reference dialog),
- Additionally a function would be necessary to discover the resolved path of an external reference, e.g. GetExternalReferenceInfo( ExtRef ),
- It would be useful to be able to specify file paths relative to the home and temp folder,
- It would also be necessary to have a Refresh External Reference script step, so that an external reference could be prompted to dynamically find newly created referenced files.
Thus a solution can first test to see if a file is present, or which file, and take the appropriate action, possibly being to create a local file and refresh an external reference to reference it.
It is an essential component in providing modular functionality:
- Helps Make FileMaker more modular
- Currently it is not possible for FileMaker to dynamically test if its' known external references are present or not, without causing a plethora of dialog boxes - requiring interaction from a user. (We can catch a perform script error, or set field error, when a file is not present, but we cannot catch the file not present error itself!)
- Making it possible to test an external reference will make it possible to remove files (optional modules) from a solution WITHOUT having to do any recoding - or any other customizing, for that matter.
- Requiring no user presence will also make it possible for automated processes, job schedulers, etc. to handle optional modules.
- Customizing solutions via modules would become FAR easier
- Developers can produce reusable modules more easily
- Customers get more befitting FileMaker solutions more quickly
- FileMaker sells more licenses
- Optional email module - if a customer does not buy the email module, it can just be not delivered - no extra coding!
- Create + use local database file (similar to HTML5 Local Database + SQLLite) - the speed of a database can be improved by freeing up bandwidth by storing data in a LOCAL database file. For example static GUI + language objects can be created + referenced locally: At the beginning of a session the login script could check to see if the "StaticGUI" External Reference points to a local file (e.g. in the documents folder or temp folder), and if not it can create a local file, refresh the external reference and use the static data from the local file, saving GBs of bandwidth.
- FM-GO modules. Product X could have hundreds of extra modules. FM-GO user just has to receive an optional module by email, install it in FM GO and start Product X, which finds the module and initializes it ... ,...