One common task when working on an HTML document in GoFiler is to save different versions of the file. Every time a copy is sent out for review, users can do a save as operation, and save a new copy of the file with a different version number. GoFiler by default allows you to create backup copies of the file (.bak files) whenever you press the save button, but that’s often too many backups, and they don’t represent true versions. The example script in this blog post then attempts to automate the process of creating different versions of files. This script will trigger when the user presses the “To Browser” button on an HTML file, and ask if the user wants to create a previous version folder of this file. If the user presses “Yes”, the script makes a new folder called “Revisions”, puts a folder stamped with the version number, date, and time into it, and copies all the HTML and images out of your folder into this previous version folder.

XBRL can be a challenging topic to tackle. There are a lot of rules to learn for it, and with 14,000+ elements in the US:GAAP taxonomy, it doesn’t look like it’s going to get simpler any time soon. Fortunately, using GoFiler and Legato, we can add some functionality to make things a little easier.

Way back in LDC #39, we discussed the file “ApplicationInitialize.ls” and how any script functions in it are run at application startup. With GoFiler 4.21b’s release on January 16, 2018, we’ve added support for a similar file, “ApplicationShutdown.ls”. As the name suggests, this file is called when GoFiler shuts down. This is a pretty powerful feature because it lets you do things to “clean up” your environment if you’ve modified it with other scripts or if you want to return the system to a desired state after using the application.

In past blog entries I’ve written, the topic is often about simple scripts. It’s covered a couple hundred lines of code, and the script usually handles a single function. This means that every script that’s been covered so far has been relatively simplistic in structure, with no more than 10 or so separate functions. With so little code, a script can still be easily maintainable even if no thought is given to how it’s put together. The design of the application is less important in these cases. However, what if you want to do a larger project? What if your script is going to include multiple UI screens and integrate with multiple systems? This is where you would want to pay some attention to design and apply some software design practices to the script to ensure that you get the best possible result. The blog post this week will not contain an example of the script but will rather discuss how we can apply some software engineering principles to Legato design to avoid common pitfalls.