One of the big new features in FileMaker Pro 18 is something that not everyone will know what to do with at first. FileMaker describes it as :
Use a preview release script step to save a copy of a FileMaker file as XML. Use the XML file to more easily compare changes and updates to your custom app.
This is the new Save As XML script step. The heading for that quote on the What’s New page is called “File version comparison“.
I’m not completely comfortable with this description of the step as I don’t think it’s accurate, but instead I’d like this description to somehow state that this is one of the biggest changes in FileMaker in a long time, and will be amazingly critical to the future of the platform.
So how can it be this big of a deal, but also be not quite right?
To start with, what is this step?
This step saves a copy of your FileMaker file in XML format. It’s that simple. This step is a way to document 100% of structure of the file in a well formed, structured, text document.
This is different from we’ve had in FileMaker in the past, in that this new XML is totally complete. You can use this XML to recreate an identical version of the file, that would behave exactly the same. None of the documentation tools, or reports ( including the DDR and BaseElements ) we’ve had in the past, would do this.
So the “really big deal” about this is that it’s obvious what the next step is in being able to accurately document the structure of a FileMaker file : it’s that you can use that document to build a FileMaker file, automatically.
This functionality to recreate a file from XML doesn’t exist in FileMaker 18. However, you can tell from the way this Save As XML step is built, and from what’s explicitly stated in the roadmap is that the idea of building a FileMaker file from the XML is planned. We will be able to at some point pull structure from a FileMaker file, and push structures to a FileMaker file.
Big picture
The greatest strength of the FileMaker platform is its integrated environment. Find me one other platform where you can do the sorts of structural changes FileMaker developers do every day that just plain work. Developers on other platforms can’t comprehend how simple it is to develop in FileMaker, the concepts that are core to how FileMaker works don’t exist in other platforms.
This is what makes FileMaker a very Rapid Application Development platform. In the age of RAD, Low Code, No Code, FileMaker is out on top for lots of things.
However this strength is also a weakness. Not having a way to easily document in text what changed, or to use so many of the tools that other developers take for granted means that some things are harder than they should be.
This new step, and the changes documented in the roadmap are going to be the step up that brings us the best of both worlds. All of the text based tools that other developers take for granted, all of the change management and process management that wasn’t always easy in FileMaker before.
I’m looking forward to this in a big way.
So what about the DDR and BaseElements?
So the first question I was asked after BE 18 came out, was : are you going to use the new XML in BaseElements? Well BE 18 is out in beta, and the answer is no.
The reason why is for some really crucial things that BE relies on, the data just isn’t there in the new XML step in a format that is useful to us.
So for example, in a calculation, you might use 2 fields, 3 custom functions and a plugin. The XML step just includes the text of the calculation. The DDR includes a breakdown of all of those fields, CFs, and plugins, and all the whitespace and functions used as well.
The biggest thing in BE is it’s use of “references”. A reference is a place something is used. The DDR tells us this, and the XML doesn’t.
The XML doesn’t need the broken down references to recreate the calculation, just the text. BE needs the references to be useful.
So for now, even though the XML Step contains more information that the DDR doesn’t, like layout parts, and a few other minor things, at the moment we can’t do without the DDR.
The future?
I’m still wrapping my head around the new XML Step and the future possible insert XML options. What this means for BaseElements is not quite clear. BaseElements isn’t going away and the need for it as a development tool will not disappear with the new steps.
We will still need good Analysis tools that do the hard work that BaseElements does, and give us insights about our solutions.
Whether or not that means that the new XML step should be part of BE is up in the air. At least for now anyway 🙂
So as you start playing with the new XML step, let us know your thoughts.