ISO FileMaker Magazine

Longtime FileMaker developers have often used the database itself to store values for various user interface settings. This is valid, because, where else would you store them? A common approach is individual fields. However, there are a few problems with this.

First, it adds "noise" to your data structure, making it harder to distinguish between actual data fields and those used for other purposes. For example, you might ask, "Is this an actual data field or is it used for something else?"

Second, FileMaker’s data transfer over the network is essentially all or nothing because every field in a table must be transferred. I've seen solutions with literally thousands of fields - every one of them, and their contents, is being sent over the wire.

This is not an ideal situation, but it can be easily mitigated by migrating to a system that addresses both issues. Furthermore, you can take additional steps to move this data just one table away and still maintain the same benefits for your user interface.

This video presents a modern approach to managing your user interface settings. By learning from it, you may also gain insights into other ways to use JSON in your development.

Every solution starts out like an infant. It knows very little and works hard to manage your solution's data as it becomes a productive citizen of your digital society. As it grows, your solution will need to offer a variety of options. User A prefers things one way, while User B another.

Your job, as the developer, is to accommodate those whims and preferences, or settings as we’ll call them, in the most efficient way possible. As is somewhat typical, you may be halfway through development when you stop and ask yourself if there's a better way to manage the growing list of settings.

In this video, I showcase an effective method for managing solution settings. By combining popular FileMaker techniques, we can consolidate, present, and manage settings in a highly streamlined way. Whether your solution is decades old or a brand new build, there is always something new to learn about handling data. We will look at how to combine JSON with solution settings and how easy it can be to simplify the process.

The first and most common way you'll likely use JSON within your FileMaker solution - should you choose to adopt it for this purpose - is as your primary method for passing script parameters.

If you haven’t done so yet, it is highly recommended that you use JSON for script parameters. Not only does this provide an opportunity to become thoroughly familiar with the format, but it also helps you understand the most common method of transmitting data when working with nearly any internet-based API.

JSON is not only easy to read when formatted but also quite efficient compared to formats like XML. Using it as your default method for passing script parameters is a straightforward transition. In the associated video and technique file, I walk through the most common methods for using JSON in script parameters and discuss key considerations when making this choice.

If you're developing in FileMaker and haven't invested time in learning and using JSON, you're at a significant disadvantage. JSON is not difficult to learn, and it's used in so many areas of modern development that it's crucial to get familiar with it if you haven't already.

In this video, I begin with the basics of JSON and its implementation within FileMaker. Once you start using it, you'll find it's valuable for much more than just passing parameters. While passing parameters is one of the most common use cases — allowing you to pass multiple values easily — JSON also supports a wide range of applications, from creating UI features to saving the state of tabs, layouts, user preferences, and even capturing metadata about your stored data.

Additionally, many advanced FileMaker features, like web viewers, rely on JavaScript and JSON for functionality. As you explore data exchange between applications, you'll see JSON frequently in modern APIs as well.

Make sure to take full advantage of this multi-part video series, where I'll cover the various ways you can leverage JSON within FileMaker. This knowledge will significantly expand what you can do with the platform.

Our world of software development is changing rapidly! With AI influencing the way we develop, it becomes increasingly important for developers to become informed about the tools which help them become more efficient.

Fortunately, we still live in a world where people have to coordinate and organize code. Even if AI can create near-flawless code in some cases, it doesn't create the ideas. Humans are the creative force. Whether you're using a simple Find & Replace to refactor some functions, or having AI create your next powerful JavaScript for your killer Web Viewer interactions, you still need to know about your available tools.

In this video, I walk you through a recent revision to an older tool I had been using to ease the amount of typing I have to do when using JSON as the parameter passing method within FileMaker scripts or when interacting with an API or anything else that uses JSON. No joke, the content in this video and the associated technique file can save you literally hundreds of hours when used effectively. I'll show you how.

JSON, JSON, JSON! If you haven't gotten used to it yet, you'd better start. It's the way you communicate with the web. It's the structure that's winning. XML is too verbose, and .tab and .csv aren't always clear enough.

So, what are some of the ways you can create JSON within FileMaker? Here are just a few:

1. Create a calculated field of it.
2. Use ExecuteSQL() to return it.
3. Use Execute FileMaker Data API [ ].
4. Write a looping script.
5. Or... you can just export it.

This last method is often the most optimal for getting your data into the JSON format to meet whatever requirements you may have. You can further modify this JSON using a variety of tools to achieve the perfect result.

In this video, and the associated technique file, I provide the knowledge and code necessary to simply export your data as JSON and be done with it. No matter what you need and where you need it, you can use multiple exports from however many tables desired to end up with the needed JSON result.

Thank goodness JSON was implemented within FileMaker. Without it, we would still be using a variety of other methods for handling multiple parameters within a FileMaker script. Using JSON, we now get the double-sided benefit of 1) having an efficient serialization of key/value pairs as inbound parameters and 2) it just happens to be the standard which most of the rest of world is using for a large chunk of how things interoperate.

In this video, and the technique file, I'll showcase a few examples of how you can receive and work with inbound parameters when using JSON as the method for handling them. We discuss script results, clean-reading code and the final example provides a very useful custom function for the auto-instantiation of JSON-based script parameters into their FileMaker scripting counterparts.

Using the provided JSONVariables custom function is a great alternative to individually parsing all of the inbound parameters. It doesn't replace the need to initially declare your variables, but it does provide the opportunity to have cleaner reading self-documenting code. If you've not used JSON for handling your parameters before, then you should start right now and use this video and file as guidance!

Having created recent videos about accessing APIs via REST, and extracting the free JSON data as well, it would be a glaring omission if I didn't address our need to manipulate the JSON FileMaker provides us with. Yes, the work to put your FileMaker data into structured JSON has already been done. But, the JSON you need for your designated API is always going to be different than that.

Fortunately, we have access to the amazingly powerful and fast JavaScript engine built into each and every Web Viewer. What we need to capitalize on are the free open source libraries which help us get the results we need.

JSONata is a long standing powerhouse when it comes to manipulating JSON within JavaScript. Updates as recently as two years ago, to the eight year old library, moved it from a more linear synchronous model to an async model. This means we need to learn a bit about JavaScript promises and how we can use JSONata's own tools to easily manipulate our FileMaker JSON into what's needed. This video and the associated technique file will provide you with the tools which will help accomplish the integrations you're trying to solve.

Coding software solutions offers the fascinating realization that there are always multiple pathways to achieve the same goal. Sometimes the methods we're familiar with may not be the most optimal, prompting us to expand our knowledge to explore alternative approaches.

This video explores precisely that theme - the comparison between older and newer methods of accomplishing the same task. The advantage lies in the fact that newer methods often come with additional features or benefits. This is particularly true when it comes to obtaining the current record data as a JSON object. Historically, we've relied on ExecuteSQL to extract field names and values from the current record or a set of records.

In this video, I delve into the existing options using ExecuteSQL for creating a JSON object of the current record data. This method is effective in various scenarios. However, accessing related data can be time-consuming, especially when constructing SQL joins accurately requires significant mental effort. Unless you're a SQL expert, this may not be the most efficient use of your development time. Fortunately, recent versions of FileMaker have streamlined the process, making it exceptionally easy, with an alternative method, to extract any data from any record and convert it into the precise JSON object needed for passing parameters or interacting with external APIs.

Developing software in FileMaker can be such a joy when you're able to solve so many problems so quickly. There is, however, a point where you start to solve so many problems that your solution starts to slow down and you find yourself wondering why.

Most commonly, it's the result of cumulative features compounding to make your solution slower and slower. Without careful consideration of the user interface, and how features are presented, it's easy to create a solution which starts to lag over time.

In this video, I show how portal filters really work and how to address the issue of a portal used for a very simple selection process. In most cases, your portal is only going to show a fraction of the number of fields found in its table. To this end, you must learn how to replicate the native portal filtering feature. Filtering with JavaScript/JSON is one of the most powerful ways to present data in both an efficient and faster way.

Finding your FileMaker solution is feeling slower as time goes by? You need the content covered in this video!