Overview

I'm copying from the concept of Developer layouts here, scripts can generally use Developer layouts, but in my opinion there are some good reasons to create specific layouts for scripts when they have to access tables.

Benefits of Script layouts

  • Ensure better performance: because Script layouts are limited to the Form view method they will never slow down solutions based on FileMaker 11 or earlier versions when scripts need to loop thru records.
  • The Suppressible Triggered Scripts practice is hardly applicable in already existing big solutions, Script layouts are trigger-free to avoid interferences of triggers and scripts
  • If you want, you can keep summary fields in Developer layouts without worry about affecting script performance
  • In the header of Script layouts can be placed useful notes, like external scripts that may use the layout
  • Especially when integrating AppleScript within a FileMaker solution, even a small modification to a layout (like removing a field from the layout, or enabling it just in find or browse mode) can break the AppleScript that uses it. A Script layout exists especially for scripts, so you are sure you are not going to alter it for any other reason, while you can continue to confidently improve the developer layouts as needed without the worry of breaking some script.

Guidelines

Following the standards outlined in Table occurrence naming for developer tables. This proposed best practice suggests you create a correspondingly named layout with the following features. Keep the names the same because a unified structure is easier to follow.

  • Always hide the layout within the Manage Layouts dialog by unchecking it. (Don't allow it to be viewed)
  • Use the color Cyan in the header as a visual reminder about the layout is a script layout.
  • Identify external tables within the header by adding the file name (including .fp7)
  • Limit the view method to Form in order to avoid performance issues with FileMaker version 11 and earlier
  • Do not assign any trigger for Script layouts in order to avoid any interferences with scripts
  • Instead of the @ prefix (used for Developer layouts) use another character (I like § that reminds me something like a gear and a stylized 'S' too) in order to distinguish Script layouts.
  • No labels

3 Comments

  1. Jeremy Bante

    These sorts of layouts are a worthwhile practice. A couple things I do when I do them:

    I always name the layouts: "TableOccurrenceName: Blank". This is more self-descriptive than any typographic convention or sigil could hope to be, which will be especially useful for the maintenance developer after me who does not know my conventions.

    The layouts have absolutely nothing on them. No fields. No notes. No header or footer. Just a completely empty body. This minimizes the performance impact of the layout.

    If there is going to be a visual element on the layout to identify the layout as a script layout, please use something more than a color. Perhaps a text object saying "This layout intentionally left blank." Folks with the most common forms of colorblindness can still discern cyan, but that's only a small part of it. To paraphrase Matt Groening, a good design is evident if all important information is still discernible in silhouette. As a heuristic test, I often open my computer's accessibility settings, turn the display to grayscale and maximize the contrast. If the design works in black and white — not grayscale, solid black and solid white — that's a good sign.

    1. Gianluca Del Maschio

      Your points are all good if you don't need to work with AppleScript as I need in some occasions. In fact AppleScript in order to accomplish some tasks needs the presence of fields on the layout, and so under this condition also the name "xxx: Blank" is not so appropriated. I simply tough to copy the Developer tables naming convention, and think it is clean to have layouts "@ TableName" and "§ TableName" stacked one above the other in Layout Management window. Also a modification to your suggestion like "TableOccurrenceName: Script" looks perfectly well to me.

      I agree to the necessity to identify the layout primary with something more than a color, this could be a title-sized text in the header of the layout like "Script layout: " followed by the name of the base table (or table occurrence, I have to think about it), and then other notes if needed like a summary of external applescripts using the layout.

      I like your suggestion about black and white test, tomorrow I will try it on the last layouts I designed to discover if I did a good job or need to learn something more! Also I will update my post including your suggestions and maybe a screenshot as an example of the current definition.

      1. Matt Petrowsky

        One other reason for not limiting these layouts to being blank are certain steps like Copy All Records. There are techniques such as Virtual List where using Copy All Records allows you to push a tab separated found set of records into $$GLOBAL.VARS - where it can be parsed for display. This also requires fields present on the layout.

        On the semantic side of things, I have always called such layouts "Utility" layouts. Does "Script" layouts make more sense to people?

        Would it be good for us to define certain types of utility layouts and attempt to promote suggested prefixes? For example, as a best practice, if I opened a solution and saw the following I would find it quite beneficial.

        In my mind there is a divide when it comes to layouts. Those which are seen (typically UI or "Interface" layouts) and those which are not ("Utility" layouts). The later are composed of print layouts, developer layouts, scripting based layouts, localization layouts and possibly others. What other "types" of layouts are there.

        With regards to identifying the layout via methods other than colors, I highly suggest we leverage what we have available. For FileMaker 12 and forward, my suggestion as a best practice is that we promote the use of the available merge aliases to the Get() functions. Such as

        Layout = {{LayoutName}}
        Table = {{LayoutTableName}}

        In the Standards.fmp12 file the @Developer layouts use these values within the header area.