Needs additional info

This area is not yet completed. More info coming.

  • Script folders are used to provide a basic structural outline as follows
    • Developer
    • Application
      • Startup
      • Shutdown
      • Menus
      • Shared
    • User Interface
      • Layouts
        • [Name of folder matches Layout Name]

The structure outlined here is only an initial core structure. I does not represent limitations to the origanization of your solution. The goal is to facilitate the basic skeleton common to all FileMaker solutions. The extended organization beyond this initial suggested structure is up to the solution and developer.

Addition coming

Add a screenshot of folders as well

Script Parameters

The Best Practices section of this website includes this page listing recommended custom functions for handling parameters passed to and from scripts.

  • No labels

5 Comments

  1. Anonymous

    I don't think organizing by Layouts is as useful as by functional areas of the solution (invoicing, payment entry, etc.). Some scripts will be called from multiple layouts.

    I like to keep my triggered scripts in their own folder.

    Tom Fitch - FileMaker Pro Certified Developer - Portland, Oregon 

    1. Matt Petrowsky

      I should clarify this diagram. The purpose of using a Layouts folder is to ONLY put scripts in those folders which uniquely exist on that layout.

      Other scripts which are used solution wide would be within the "Shared" or a "Common" folder.

      Of course, I'm wanting to get feedback from others about this. It maybe that the following works better.

  2. Anonymous

    What about a Utilities folder?? I have mine above the Application in this structure, covers things like standards routines for dialog boxes, error handling

    I also start each file with a TEMPLATE script while developing

    1. Matt Petrowsky

      My initial thought process on this was that "Shared" was the name for the "Utilities" or "Common" folder. Much of what many developers argue against is semantics. I'm personally beyond the semantics at this point in my development career as long as what's used make sense.

      In the sense that "Shared" scripts within the Application are shared across the whole solution, I might wonder what "Utilities" are with regards to what the solution does.

      Oh damn, am I arguing semantics?

      Anyway, my point with initial organization is a starting point ONLY. To figure out what is common amongst ALL FileMaker solutions. Beyond that it's up to the developer and solution. The objective is not to limit the developer but to clarify basic structural commonalities between all solutions.

      If your solution was opened and it read

      • Application
        • Shared
          • Dialog Utilities

      Then I would certainly understand what's stored in that folder. (wink)

  3. Jeremy Bante

    Would it be better to standardize on the format of multiple named parameters than on the function(s) that (create and) parse them? Any specific functions that work with that format might then wind up in the Accepted Techniques area.