Scripting Methods...

[Ocean West]

Ok since there seems to be an infinite way to do this I am just curious of which seesm to be the most effective for development and maintaining scripts.

Method A

For each "module" such as "Customers" I have one script "Manage Customer" inside that script I test for the script paramerters. On my layouts all functions or tasks that involve customers perform this script passing the appropriate paramater, such as New, Delete, Find, or some specific scripting function. This greatly reduces number of scripts as anything that deals with Customers can be manged via this single script.

Method B:

The other method would be to write a Function type script that does one thing like creating records. Depending on what module I am in when clicking on the New button it would perform this script the script would test to see my context (layout or some set variable) then perform the assigned steps for that module. This method allows me to put a button on a layout sans (without) script paramaters. I can then copy and paste this button to a new layout with out having to remember to change the button's parameters.

I am curious which method is most favoried. I like to reduce the number of scripts to what is considered essential, adequate, and effective.

[T-Square]

I think that you'll find this to be a pretty personal decision among developers.

I've tried Method A (in other programming environments), and felt that the long scripts got difficult to keep clear in my head. To be honest, I don't see how you'd accomplish this in FM, since there's no real way to create separate functions in the scripting language. So, you'd basically be parsing your parameters in one script so that you could trigger another set of scripts.

Method B works well for me with processes that are essentially the same from one module to the next--such as your Add record example. I currently use that approach for things like adding records (passing the destination layout as a parameter), and managing layout windows (opening, resizing, hiding).

For myself, I go with a different approach: I create a lot of smaller scripts, each of which is optimized to accomplish a particular task. I use a simple naming convention where each script gets its module as the first word, followed by a clear wording of its purpose--e.g., Invoices - AddLineItem. I don't know that FM lets you create module-based libraries; this is my way around it.

I find that it is much easier to pick apart a script when it is shorter and simpler and focused on fewer tasks. This breaks down when there are a lot of tasks embedded in one process, and you end up with script A calling B calling C, except when the user clicks Yes in which case A calls D calls B calls E.

Debugging between different scripts can get troubling at times. The biggest headaches I have are keeping track of what script has called another and what window/layout are currently active. It gets to where I put comments in the scripts to identify both when needed.

David