Script patterns – Test then act (assessment)

Over the last two days, we have detailed four scripts to solve the problem proposed – test for the FileMaker client being used, and navigate to a specific layout designed for the client.

Now it is time to compare and contrast these solutions and come up with a final selection. The four solutions are:

• #1: Use standard If/Else If
• #2: Test client and go to layout by calculation
• #3: Run a subscript for layout navigation
• #4: Use a layout routing table

When assessing each solution, I will refer to them by number. Due to space constraints I'm not going to repeat each script here. If you want to see the details you can refer to the previous postings:

​Script patterns – Test then act​

​Script patterns – Test then act (cont.)​

What criteria can we use for assessment?

Perhaps the most important thing about any solution is that it works. And it needs to work in all defined scenarios. To test each solution we would construct a test suite and confirm that all solutions pass for all tests. Let's assume that we have done that and every solution is solid.

The other criteria we can assess with are:

• Readable – Can a developer quickly read and understand the logic?
• Maintainable – Is it easy to access and update the logic?
• Extensible – Is it built to easily extend the processes?
• Usable – How easy is it to apply in another script or file?

To make this assessment more objective, we will score each solution script out of five (5) for each criterion.

Readable

The standard If/Else If structure in #1 is very readable. It follows a logical pattern of testing for each client and ending with a default. The PatternCount tests are self-documenting and do not require any comment. The SystemPlatform test for WebDirect has an inline comment.

Similar logic is used in #3. However this is less readable than #1 due to the repeated If/End If structures. This also adds to the number of steps required because an Exit Script is used for every If statement. The default layout used when all tests fail is not clear because it is on a line after the If/End If blocks.

The scripting in #2 is the most compact – just two lines. This means that the readability is somewhat obscured by the client calculation being inside a Set Variable step. The script in #4 is similar to this, with just three lines. Again the logic is obscured inside Set Variable steps. Both #2 and #4 may benefit from an explanatory comment.

Scoring: #1 = 5, #2 = 4, #3 = 3, #4 = 4

Maintainable

In #1 and #3 the logic for determining each client is directly accessible. If it needs to be updated for any reason, it can be edited inline (without opening a dialog). The target layouts are selected from a list and therefore can be independently renamed without breaking the scripts.

With the calculation logic being inside Set Variable steps in both #2 and #4, this means that edits are one click away inside a dialog. This is balanced by the ability to update all client and routing logic in one place rather than in separate If statements.

However, as previously mentioned, both #2 and #4 tie their logic directly to layout names. This means there needs to be some care taken if layout names are updated.

A downside with #2 is that the layout names must exactly match the calculated $client name. This is not true for #4 as it allows any layout name to be used for the target. This makes it easy to update the routing table if a layout name is changed.

Scoring: #1 = 5, #2 = 3, #3 = 5, #4 = 4

That is a good start. Let's finish this assessment tomorrow.