{"id":128,"date":"2018-06-10T15:35:08","date_gmt":"2018-06-10T15:35:08","guid":{"rendered":"https:\/\/panditaseaman.com\/infocypher\/?p=128"},"modified":"2023-06-09T18:36:54","modified_gmt":"2023-06-09T18:36:54","slug":"a-filemaker-framework-reduces-development-and-maintenance-costs","status":"publish","type":"post","link":"https:\/\/panditaseaman.com\/infocypher\/a-filemaker-framework-reduces-development-and-maintenance-costs\/","title":{"rendered":"A FileMaker Framework Reduces Development and Maintenance Costs"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-post\" data-elementor-id=\"128\" class=\"elementor elementor-128\">\n\t\t\t\t\t\t<section class=\"elementor-section elementor-top-section elementor-element elementor-element-76bd8f48 elementor-section-boxed elementor-section-height-default elementor-section-height-default\" data-id=\"76bd8f48\" data-element_type=\"section\" data-e-type=\"section\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-4b749333\" data-id=\"4b749333\" data-element_type=\"column\" data-e-type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-744f50c6 elementor-widget elementor-widget-text-editor\" data-id=\"744f50c6\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>The FileMaker platform is\u00a0super\u00a0flexible and makes it incredibly\u00a0easy to start building custom software quickly. Yet it&#8217;s this very feature that too often leads to coding nightmares:\u00a0poorly planned development,\u00a0code\u00a0that is difficult to understand or translate to other developers, and solutions that become difficult and costly to maintain long-term. Years after it was created, it is\u00a0easy to forget how a solution was developed, even if the solution has never changed hands,\u00a0and the more complex an app becomes, the more likely it is to break because of forgotten or invisible\u00a0dependencies. If the solution does change hands, it can\u00a0be more difficult to decipher.<\/p><p>We\u00a0strive to evolve\u00a0our development systems and processes to minimize these scenarios. One way we&#8217;ve done that is to create and train developers on a development framework for our FileMaker solutions based on software industry best practices and innovative FileMaker-specific practices\u00a0that vastly reduce dependencies and code redundancy. We perpetually refine\u00a0our framework\u00a0to\u00a0allow\u00a0us to create apps that are\u00a0easy to modify and\u00a0maintain,\u00a0while retaining enough\u00a0flexibility to take full advantage of FileMaker&#8217;s rapid development features for customizing\u00a0software to serve our clients&#8217; unique organizations.\u00a0<\/p><p>Our framework borrows from the\u00a0time-tested principles of the model-view-controller (MVC) design pattern and object-oriented programming (OOP). These principles allow us\u00a0to organize and code solutions in a way that is modular, easily extensible, and self-documenting.\u00a0More specifically, many of the ideas on which\u00a0our framework is based come from\u00a0WebObjects, Apple&#8217;s integrated suite of Java frameworks for rapidly developing scalable, sophisticated Internet and Enterprise applications. Apple no longer sells WebObjects, but we have done our best to adapt some of the brilliance behind\u00a0that suite of tools to FileMaker development.<\/p><p>Below is a brief overview of how we use MVC and OOP principles along with standardized methods in FileMaker\u00a0to reduce code redundancy in our solutions to\u00a0prevent our code from becoming a nightmare for our clients.<\/p><h2>Model-View-Controller Design Pattern<\/h2><p>The MVC design pattern separates a software solution into 3 parts: the Model, which describes the structure and characteristics of data stored and\u00a0used by the solution, the View, or the visual presentation of information to a user, and the Controller, which controls how the Model, View and the user of the solution interact.<\/p><p>In the FileMaker platform, the Model is most closely represented by the tables, fields, and\u00a0relationship graph that describe the data\u00a0in a solution. The View is most closely represented by layouts and layout elements that allow a user to interact with the solution. The Controller is most closely represented by the\u00a0built-in FileMaker functionality and custom built scripts\u00a0that allow\u00a0a user to use\u00a0layout elements to create, modify or delete\u00a0the data\u00a0and control the way data is displayed to the user.<\/p><p>The advantages of using the\u00a0MVC pattern include:<\/p><ul><li>Better organization of the Controller\u00a0into logical groups based on functionality of the interface on screen layouts (View)\u00a0and the data structure in the Model so that the solution can be self-documenting with minimal effort.<\/li><\/ul><ul><li>Allowing layouts (Views) built for different purposes (iOS vs. Web vs. Desktop, for example) to use the same dataset without complicating the same interface file.<\/li><\/ul><ul><li>Making modifications and updates to the Views\u00a0simpler because they can be switched out easily without affecting the underlying data model.<\/li><\/ul><h2>Object Oriented Programming Principles<\/h2><p>The acronym &#8220;SOLID&#8221; describes the following\u00a0five basic principles of object-oriented programming,\u00a0summarized by Robert C. Martin\u00a0in his paper\u00a0<em><a href=\"http:\/\/www.cvc.uab.es\/shared\/teach\/a21291\/temes\/object_oriented_design\/materials_adicionals\/principles_and_patterns.pdf\">Design Principles and Design Patterns<\/a>.<\/em><\/p><ol><li><strong><em>Single Responsibility Principle<\/em><\/strong>: a class, or template representation of an object in the real world,\u00a0should have only a single responsibility.<\/li><li><strong><em>Open\/Closed Principle<\/em><\/strong>: software entities should be open for extension but closed for modification, meaning elements of software should allow extensibility without having to be modified.<\/li><li><em><strong>Liskov Substitution Principle<\/strong><\/em>:\u00a0objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.<\/li><li><em><strong>Interface Segregation Principle<\/strong><\/em>:\u00a0many client-specific interfaces are better than one general-purpose interface<\/li><li><em><strong>Dependency Inversion Principle<\/strong><\/em>:\u00a0High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.<\/li><\/ol><p>The intention behind these cryptic-sounding principles is to make software design more understandable, flexible and maintainable. Many modern programming languages follow the principles of OOP to varying degrees. Though the FileMaker platform is not a programming language of this sort, we&#8217;ve found that the principles of OOP still provide ways to make our solutions more understandable, flexible and maintainable.<\/p><h2>How We Use MVC and OOP in the FileMaker Platform<\/h2><p>Because FileMaker combines layouts, scripts, and data structure into one integrated development platform, it is not possible to completely separate the Controller out of a FileMaker solution, since some of the Controller is built into\u00a0FileMaker itself.\u00a0Instead, we use what&#8217;s commonly known in the FileMaker developer community as\u00a0the data separation model to separate our solutions into at least 2 files: the data (model) and one or more interface (view) files, and divide the scripts\u00a0(controller) between them.<\/p><h3>Data File: the Model (and Controller)<\/h3><p>Scripts in the data, or Model, file\u00a0are organized as &#8220;methods&#8221; describing table &#8220;classes&#8221; in\u00a0the data model:<\/p><ul><li>Since the introduction of the unified file system in version 7 of the FileMaker platform about a decade ago, we&#8217;ve been using what&#8217;s now known as the &#8220;selector connector&#8221; method in the FileMaker developer community to\u00a0design the FileMaker relationship graph and\u00a0keep our scripts context-free. We also use the full name of the table in our Table Occurrences so no one has to guess what our abbreviations stand for. Less guessing leads to faster development with fewer mistakes.<\/li><\/ul><p><img fetchpriority=\"high\" decoding=\"async\" class=\"aligncenter wp-image-132 size-large\" src=\"http:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/RelationshipGraph-1024x397.png\" alt=\"\" width=\"800\" height=\"310\" srcset=\"https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/RelationshipGraph-1024x397.png 1024w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/RelationshipGraph-300x116.png 300w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/RelationshipGraph-768x298.png 768w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/RelationshipGraph.png 1208w\" sizes=\"(max-width: 800px) 100vw, 800px\" \/><\/p><p>\u00a0<\/p><p align=\"center\"><em>Context-Independent\u00a0Data\u00a0Modeling in FileMaker<\/em><\/p><ul><li><p>CRUD in the general software world stands for the basic functions performed on persistent data: Create, Read, Update, and Delete. FileMaker renders the &#8220;read&#8221; action moot because we are always able to &#8220;read&#8221; the data by placing fields on a layout. CRUD in our framework\u00a0substitutes &#8220;read&#8221; with &#8220;report&#8221;, because we keep reports and charts in the data file. Displaying reports and charts\u00a0is the only functionality that exposes the data file to user interaction.<\/p><\/li><li><p>A set of scripts control CRUD (create, report, update, and delete) functionality. This means all records in our FileMaker solutions are created, edited and deleted in a standardized way that minimizes bugs resulting from code repetition. This method\u00a0of organizing scripts allows us to abstract the basic functions of persistent data and attempts to\u00a0mimic\u00a0what&#8217;s called Enterprise Object (EO) modeling in OOP.\u00a0The main purpose of doing it this way\u00a0is\u00a0to organize\u00a0scripts\u00a0so it&#8217;s\u00a0simpler to document\u00a0our clients&#8217; business rules within the code structure\u00a0itself.<\/p><\/li><\/ul><p>\u00a0<\/p><figure id=\"attachment_134\" aria-describedby=\"caption-attachment-134\" style=\"width: 585px\" class=\"wp-caption aligncenter\"><img decoding=\"async\" class=\"wp-image-134 size-large\" src=\"http:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModel-585x1024.png\" alt=\"\" width=\"585\" height=\"1024\" srcset=\"https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModel-585x1024.png 585w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModel-171x300.png 171w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModel-768x1345.png 768w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModel.png 806w\" sizes=\"(max-width: 585px) 100vw, 585px\" \/><figcaption id=\"caption-attachment-134\" class=\"wp-caption-text\">OOP-ish EO Modeling in FileMaker<\/figcaption><\/figure><ul><li>Our scripts are named\u00a0as commands that succinctly describe what they do. You may have also\u00a0noticed that our script names in the image above explicitly\u00a0name parameters, and clearly identify\u00a0which parameters are required vs. optional.\u00a0Multiple named parameters are passed into a script and script results are passed back to any calling script in a consistent way,\u00a0using a standard set of custom functions and script steps. This &#8220;black box&#8221; method of abstraction\u00a0provides a few advantages:<ul><li>It eliminates the majority\u00a0of dependencies that create\u00a0a tremendous amount of\u00a0confusion and time spent tracing\u00a0long,\u00a0complex scripts written by other developers or even ourselves.\u00a0<\/li><li>It minimizes the need to look inside subscripts to see how they\u00a0work.<\/li><li>It makes scripting more modular and\u00a0reusable, so that it&#8217;s easier to extend functionality.<\/li><li>It allows vastly better <a title=\"How We Do FileMaker Script Error Handling\" href=\"\/blog\/filemaker-script-errors-handled\" data-entity-substitution=\"canonical\" data-entity-type=\"node\" data-entity-uuid=\"fe29b021-7bcf-4ff7-95c6-f41c96807349\">error handling<\/a> by eliminating\u00a0the need for a complex\u00a0nest of conditional statements to capture errors.<\/li><\/ul><\/li><\/ul><ul><li><p>Another\u00a0set of scripts represent\u00a0tables in\u00a0the data Model, with a folder for each table and the scripts within that folder written as if they are methods describing an object class\u00a0with the table name. The scripts within those folders further describe the table &#8220;class&#8221;. These scripts, along with a standard set of field naming conventions, allow us to\u00a0create the abstraction needed to avoid having to rewrite repetitive script steps to create, update and delete records in each table of the solution.<\/p><\/li><li><p>Any custom functionality for CRUD behavior is written by extending the\u00a0functionality of the standard CRUD scripts without having to modify them.\u00a0Scripts in the data file are abstracted black boxes that accept parameters and return one or more results without ever needing user interaction or detailed knowledge about the code inside them.<\/p><\/li><li><p>The parts of the Controller that may also be in the data file are a set of scripts for the user session, reports, security, server schedules, and integration with other software solutions.<\/p><\/li><\/ul><h3>Interface File(s): the View (and Controller)<\/h3><ul><li>We use standardized scripts to control interface components, including email, fields, layouts, navigation, record control, user input, and windows. This minimizes code redundancy, which reduces the possibility of introducing bugs into the solution\u00a0and makes it easier to find and fix them when they do appear.<\/li><\/ul><p><img decoding=\"async\" class=\"aligncenter wp-image-133 size-large\" src=\"http:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/ViewControl_Scripts-419x1024.png\" alt=\"\" width=\"419\" height=\"1024\" srcset=\"https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/ViewControl_Scripts-419x1024.png 419w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/ViewControl_Scripts-123x300.png 123w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/ViewControl_Scripts.png 498w\" sizes=\"(max-width: 419px) 100vw, 419px\" \/><\/p><p align=\"center\"><em>Script Organization in the Interface File<\/em><\/p><p>\u00a0<\/p><ul><li>Scripts that are kept in the interface files are limited to only those\u00a0which control user interaction. <strong>There are no CRUD-related scripts in the interface file.<\/strong>\u00a0This is an important part of the MVC design pattern which enables multiple interface files to use the same data file. Data stored in the data file is not manipulated from interface files. Instead, interface files call the CRUD scripts in the data file to modify records stored there.<\/li><\/ul><ul><li>The remaining scripts in the interface files are organized by modules, or screen\/layout groups,\u00a0layouts and layout subcomponents. This method of organizing scripts makes them\u00a0easy to find, auto-documents the structure of the interface, which makes it harder to forget how it was created and makes it much easier\u00a0to maintain the solution in the long run.<\/li><\/ul><ul><li>Because the parameters are in the script names, developers coding in the interface files don&#8217;t need to delve into the code in the data file\u00a0to be able to understand or\u00a0use the CRUD scripts. This makes development simpler, more efficient, and less prone to bugs.\u00a0<\/li><\/ul><ul><li>Other parts of the Controller that may be in the View files are a set of scripts for security scripts, server schedules, and integration with other software solutions.\u00a0<\/li><\/ul><p>\u00a0<\/p><h2>Our Development Framework Provides Extra Value to Our Clients<\/h2><p>Beyond the above, we use consistent naming conventions for fields in our tables as well as our\u00a0scripts, and consistent ways of designing our user interfaces\u00a0to make reuse of layout components\u00a0simple and efficient. We also use some FileMaker-specific tricks, such as defining business logic for\u00a0record creation and deletion in the table definition itself\u00a0to make the framework self-documenting and work\u00a0flawlessly. I&#8217;ll be writing more about these tips and tricks soon.\u00a0<\/p><p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-131 size-medium\" src=\"http:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModelFields-300x278.png\" alt=\"\" width=\"300\" height=\"278\" srcset=\"https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModelFields-300x278.png 300w, https:\/\/panditaseaman.com\/infocypher\/wp-content\/uploads\/2023\/06\/DataModelFields.png 598w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/p><p align=\"center\"><em>Standard Field Naming Conventions with Built-In Business Logic<\/em><\/p><p>In summary, the FileMaker platform already makes custom app development quicker and simpler than other ways of programming software. Using our development framework does require at least a basic understanding of MVC\u00a0and OOP principles. Yet the learning curve is worth the effort of training our developers because of the following benefits it brings\u00a0to our clients:<\/p><ol><li>Our code has fewer bugs and requires\u00a0less maintenance due to less repetitive code. The inevitable bugs that do exist are easier to find and fix.<br \/>\u00a0<\/li><li>Feature modifications are simpler to add due to the framework&#8217;s self-documenting structure, scripts that remain independent of each other, and a clear organization in the data and interface files.<br \/>\u00a0<\/li><li>Consistent development practices make it easy to explain and share work with developers when a project is big enough that\u00a0we need to hire help.<\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>The FileMaker platform is\u00a0super\u00a0flexible and makes it incredibly\u00a0easy to start building custom software quickly. Yet it&#8217;s this very feature that too often leads to coding nightmares:\u00a0poorly planned development,\u00a0code\u00a0that is difficult to understand or translate to other developers, and solutions that become difficult and costly to maintain long-term. Years after it was created, it is\u00a0easy to [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-128","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/posts\/128","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/comments?post=128"}],"version-history":[{"count":4,"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/posts\/128\/revisions"}],"predecessor-version":[{"id":137,"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/posts\/128\/revisions\/137"}],"wp:attachment":[{"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/media?parent=128"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/categories?post=128"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/panditaseaman.com\/infocypher\/wp-json\/wp\/v2\/tags?post=128"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}