This is the second in the series of posts about the Web Viewer Integrations Library.
In the previous post, I introduced to you the Web Viewer Integrations Library, a labor of obsession and passion around the web viewer object. It has been a lot of fun to put together, and I am glad to be able to share it.
A Typical Web Page
According to the web organization W3, web code should be separated into separate files with links in the index.html page for many reasons:
- Efficiency of code: the entire web page loads faster when each page has a chance to load into the computer’s memory on its own rather than one file loading everything. Additionally, it is easier to find a specific section in smaller files.
- Ease of maintenance: If a developer needs to update the look of the web page, she only needs to open the styles.css page.
- Device Compatibility: An HTML page with no style information inside can be easily adapted depending on the device. If the page is viewed on a phone, the HTML page can access a CSS file with styles designed specifically for that device.
- Web Crawlers/Search Engines: Google and other search engines read through the index.html page for the content. Finding content allows your site to be returned in these engines.
The last reason is simply that it is good practice. Standards-aware web developers separate content, style and functionality.
Adapting for FileMaker
In FileMaker, we don’t have quite this flexibility; It is a bit more difficult to work with multiple files needed for an integration. So we need to come up with a different solution. Let’s take a moment to look at those options.
Inside the Web Viewer Setup
- A calculation dialog’s limit is 30,000 characters.
Inside a Text Object
Other people put the all the text into a text object that is hidden on the layout. It does give you a bit easier access to the code and has no length restriction, but it is still difficult to modify and you always have to modify the text in layout mode.
The Chosen Solution
In order to incorporate these separate fields into the web page’s code, the content of the the HTML fields needs to be combined together into one calculation. I am using placeholder text, such as “**CSS1**” in the HTMLTemplate field to then be replaced by the content of the HTML::CSS1
There are some advantages to this method.
- An integration will work online or offline because all the code is stored locally in fields of a record.
- The text placed inside each field most likely will not come close to the 10,000,000 character limit per text field.
- Specific to this library, It is very easy to export an integration from here and place it into your custom app. As we’ll discuss in a later post, exporting an integration record is very easy.
The fact that the code is stored locally is an advantage and a disadvantage. Locally-stored code, as we said above, doesn’t require outside resources to run, but the code is static and won’t change automatically. If the jQuery library updates from say version 3.1.1 to 3.1.2, the integrations stored locally will not automatically be able to use the new features of the new version. We would have to manually go find the new version of the jQuery library and import it into the correct fields. However, this is little trouble; if our integration is working satisfactorily, there may be no need to get the newest version.
This FileMaker Web Viewer Integrations library is set up in a way that allows for an efficient implementation for any custom app.
In the next post we will take a look at the features of this file as you use it to manipulate and export an integration.
Get the Demo File
If you have any questions, please reach out to our Carafe team.