ModularFileMaker.org has done really well in 2013.  There are lots of modules available now, and the list keeps growing. One question that we are trying to answer is how do we organize our “Modules” into an “Application?  This is a topic that will likely remain beyond the scope of the Modular FileMaker spec, as it is almost antithetical to the whole approach.  Modular FileMaker specifically stays out of the Application Framework conversation. But in my own projects an organizational pattern is starting to emerge. I thought I would share it.

Start With the End in Mind

What I was looking for was a way to work in a Modular fashion throughout my application.  I wanted to be able to start every feature or function out as a “Module”.  They wouldn’t all get the full documentation nor get published on ModularFilemaker.org.  But I wanted to start them as if they would someday make it to the big time.  That way, as some modules proved useful, they would gradually get better and better organized and documented.  By the time they proved themselves, it would be relatively easy to take the final step and get published.

Video

 

Modular FileMaker Script Organization

Since the mFM spec calls for organizing and describing Modules in scripts, that’s where we will focus our efforts.  Here is how I have organized an application I am working on.  I start out with three top Level Folders.

  • FieldZync – named after the application itself
  • gi Modules – private module named for Geist Interactive
  • Modules –  the normal mFM modules

modular filemaker script organization

Development Process

As I am developing FieldZync, I start out by building Modules in the FieldZync folder.  If they are general use or are part of the application infrastructure, they go in “FieldZync Application Modules”.  This would include modules concerned with things like “Printing” or “Account Management”.  If the module is concerned with one of the domains, or subjects of the application then it goes into the “FieldZync Domain Modules”.  These would included modules that are concerned with “Invoices”, “Contacts”, etc.

As I develop the application,  some of those modules in “FieldZync Application Modules” prove to be solid and general enough, so I move them down into gi Modules. That signifies that I think these are ready for more general use, but they are not yet “publishable”. Or maybe they won’t ever get published, but they may get re-used from project to project internally.

At some point later, maybe I will decide  “Account Management” is ready for primetime.  I will do the work to get it ready for public consumption adding more docs and tests and then movie it up to ModularFileMaker.org. Once it is public, then the module makes its way to its final destination, the official Modular FileMaker Modules folder.

The modules in the “FieldZync Domain Modules” folder will probably never move down into either “gi Modules” or “Modules” as their focus is this particular application.  Those modules  are the most custom and unique.  They probably use lots of the other more generic modules, and they use each other. They are the implementation of the all the custom logic and UI for this application.

The Future

I can see a future where I have a core stable of solid Modules, many of which will be public Modules published at Modular FileMaker. Others will be internal modules, just for our internal projects.  Starting a new project will consist of bringing in the modules I need. Developing the project will consist mostly of developing those “domain” modules, that are specific to that application.  Its a bright future!