Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Big versatile script or lots of short little scripts


Feirefiz
 Share

Recommended Posts

Today I modified a navigation/child record creation script. Until now it was for two specific layouts. With a bunch of "Else If" steps I modified it to be useful for several more layouts/tables. It made sense to modify the script rather than create a bunch of new ones because this script is tied to a keyboard shortcut, and I wanted to use the same keyboard shortcut throught the solution for child record creation.

 

I then made a scripted button to go each level upward in the hierarchy. Then I started wondering what's better:

 

a) for each layout, create one little script to go up the next level in the hierarchy & attach it to a button;

b) have one script that determines the current layout and acts accordingly & attach this one script to the navigation button on each layout.

 

For a) are there any performance advantages? Or rather, any performance disadvantages for b)? Other pros/cons?

Link to comment
Share on other sites

I prefer a modification of your scenario b: each key passes a script parameter (in this instance, describing the destination) to a more generic script. You can even pass multiple parameters by using a delimiter character in the parameter (I often use "|") and parsing the parameter into variables in the script.

 

I find navigating through many similar dedicated scripts when troubleshooting/modifying a solution very annoying!

Link to comment
Share on other sites

Ooooh, very interesting! Will have to make some attempts here. Same for going to a layout by calculation…

 

As to your second point, yeah, for me it's the same with layouts; I wish you could have a layout with "parameters" so as not to have to modify a bunch at the same time if you want to change one thing on vary similar layouts. (Though maybe the newer versions of FMP cover this – not to mention tab controls, which I avoid partly because of their peculiar behavior when tabbing through fields),

Link to comment
Share on other sites

Ooooh, very interesting! Will have to make some attempts here. Same for going to a layout by calculation…

It's always great to put a shiny new tool in the toolbox!

Link to comment
Share on other sites

It depends on your priorities and exactly what your script is doing.

 

General-purpose scripts are almost always slower than scripts for particular situations. However, they're usually not slower enough to worry about.

 

Whether or not to use generalized or specialized scripts depends on what range of functionality your scripts have to cover. Without going into too much detail:

 

1. Always start with writing a specialized script, even if you're certain that your goal is a general-purpose script. This gives you a better, more concrete starting point.

2. For the second special case, write another specialized script by duplicating the first and making changes to it. Count how many changes you make. If you wind up writing a generalized script, every one of those changes is something the generalized script will have to handle, either by inferring information from context or by accepting a script parameter.

 

If the generalized version would require too many script parameters, then writing a generalized script would not be delivering on the point of writing a script: to package up a piece of functionality so that you don't have to think about how it works while you move on to other things. If a script takes a lot of parameters, you still have to think about a lot to use it. I don't have a hard-and-fast rule for how many parameters is the right number, and some parameters are better than others, cost you less of your "parameter budget" so to speak.

 

Data parameters are good. Scripts using data parameters have things like this:

 

Set Field [Table::field; $variableFromScriptParameter ]

Go to Layout [ $variableFromScriptParameter ]

 

Instruction parameters are worth more caution. Scripts using instruction parameters risk being dominated by structures like this:

 

If [$scriptParameter = "value 1" ]

# Do something

Else If [$scriptParameter = "value 2" ]

# Do something else

Else If [$scriptParameter = "value3" ]

# Do something else

End If

 

It's perfectly OK to have some instruction parameters, but not for a script's actions to be entirely dominated by them. The choice of what script to call is itself an instruction; you shouldn't have to give it more instructions. If the whole script is contained in one big If...Else If block, with no functionality outside it, that script definitely would be better off broken up into smaller scripts. The more functionality there is beyond the specific instructions, the more OK it is.

 

Also consider that specialized vs. generalized doesn't have to be all one way or all the other. If many scripts are doing similar things, but with several key details different, you can put the parts that are the same in a generalized sub-script called by the scripts handling each special case.

Link to comment
Share on other sites

jbante, thanks for the tips and info! They're helpful to think about. One situation for which I think a generalized script is probably the only way to go is when you want to attach slightly varied actions to the same keyboard command. Maybe with parameters, but I need to try these out to see whether I can get the hang of when they work.

Link to comment
Share on other sites

 Share



×
×
  • Create New...

Important Information

Terms of Use