A complex FileMaker solution may end up with many hundreds of scripts. Without any type of system for naming, the utility of being able to successfully use the Manage Scripts filtering feature becomes less useful - both for yourself and any other developer.

As a best practice, it is suggested that you choose predefined prefixes to identify certain scripts which perform known actions or have fixed associations. Using the colon (:) is what identifies the prefix from the name of the script. These should be documented in your default scripts where documentation is maintained.

The following present some useful examples. Using the prefixes of Button:, Create: and Delete:

New Customer vs. Button: New Customer

Create: New Customer vs. New Customer

Delete: Customer vs. Delete Customer

RowClick: Sidebar Select Customer vs. Select Customer

In the above examples, the keywords have been used to identify specific associations. Using the filtering field at the top of the Manage Scripts dialog means you can quickly find all scripts which are associated to "Buttons:". You should also note that there is a distinction between Button: New Customer and Create: New Customer where the button script is clearly associated to the button within the user interface (the layout), and the Create: New Customer is a general routine which is called not only by the Button: New Customer but also by any other script which may require the action of making a new customer.

Suggestions needed

Currently this page does not have a fixed list of suggestions for prefix names. It would be nice to have the community contribute to this. I've personally only used the few above.

Suggested prefixes

Button: for any general buttons
RowClick: (special type of button) for any script tied to a portal row selection
ListClick: (special type of button) for any script tied to a list row selection
Create: for any script which creates a record
Delete: for any script which deletes a record

  • No labels

4 Comments

  1. Anonymous

    I used to use [Button] blah blah blah, [Portal] blah blah blah and others for many years. Now that I'm back in the game I've stopped that and actually like just the script name without the calling button/function. Since we want scripts to be object-oriented as much as possible, we want to use that same script whether it's called from a button, a script trigger, etc. I frequently had problems with that naming standard in the past and would prefer not to go down that route again. I'm ok with the create and delete bits, though.

    Nick Chapin

    1. Matt Petrowsky

      If the code in question is to be used as common (or shared) code, then it should not be placed within a script named Button: Whatever. As per the example above. Create: New Customer is your common code which would be referenced by any other script. Button: New Customer is only the minimum required logic by the action of the button.

      It's often a "mental hurdle" for newer FileMaker programmers (I'm not saying you're new) (wink) to know when to break out their code. Simply starting from pseudo-code and putting all logic into one script, then keeping it there, is a very common thing I've seen. Because a lot of developers are in a "programmers rush" due to deadlines or some other pressure. Saying "it works, I'll just leave it like that" is why FileMaker spaghetti code exists.

      Knowing how/when to break out your code and name it appropriately comes with experience and practice.

      I would be willing to argue the point that without any standardization on naming, things get pretty chaotic quickly in even an average sized solution. Read the following two script names and tell me which one is most immediately understood.

      RowClick: Sidebar Select Student
      vs.
      Select Student

      Hopefully, you can agree the later is more ambiguous.

      Even if I have to guess what RowClick is relative to list view vs. a portal, I know that a row is being clicked, it's within the sidebar vs. another portal and it deals with selecting a student.

      This topic also goes hand-in-hand with good organization of scripts.

    2. Jeremy Bante

      Nick, I don't agree that we want scripts to be object oriented as much as possible. FileMaker is not object oriented, and imposing an object oriented structure on FileMaker can make code more complicated than it needs to be — just as much spaghetti code comes from over-organization as under-organization. However, it sounds like you're describing decoupled code, not object oriented code. Decoupling is not unique to OO programming, though OO languages do give us more tools to decouple with. Decoupling in FileMaker can sometimes require a little more creativity than with other platforms — FileMaker's priority is getting stuff done quick and easy, not being elegant in the computer science sense of the word — but decoupling is still usually worth it.

  2. Anonymous

    I've seen value using prefixes for script triggers (borrowed from Chad @ Support Group). Esp useful for quick filtering.

    OOModify:
    OOSave:
    OLEnter:
    ORCommit:
    etc

    Rgds

    Olly