FileMaker Advanced: Logging

[ferdly]

Hi All,

Debugger is great when you are coding as few of us are Mozart (who never had to edit any composition).

Moreover, I would posit that few of us are able to imagine and test all the various permutations of our code's use.

Like many of you, I presume that you have adopted a "Switch" model, where you use If-{ElseIf...}Else-EndIf where each option you *think* could happen exists within the If/ElseIf-s, and within Else you place some sort of mechanism that writes to an $$error session variable the context of the Switch condition that was not accounted for.

Indeed, I use this $$error session variable at any juncture where I believe there might be a critical juncture and when something happens or a state exists that is problematic or otherwise unaccounted for I want to see what is going on. I can debug and have the script check that I am using Developer and prompt me with these messages.

But again, this all happens in Debugger.

I would like to have a few script steps that, like the stop arrows, are inert if not in Advanced. Specifically:

LoggingOn(FileName; FilePath; WriteFileIfNoLog);

LoggingOff;

SetLoggingPersistent(On/Off);

Log(text{, email});//obviously can take an expression like $$error

LogSystemErrorsAutomatically(additionaltext {, email});

(NOTE: WriteFileIfNoLog takes an expression that can evaluate to True or False)

So, you hit a juncture where you would normally use Debugger and Dataviewer or throw some data into $$error and you just call the Log() function. You can turn logging on immediately before it for a quick hit (logging turns off at the end of the current script by default).

Otherwise, you can turn LoggingOn at the beginning of your script and call Log() at various points in your script.

The LoggingOn FileName can default to the scriptname and a timestamp concatenated.

The LoggingOn FilePath can default to a Log folder somwhere within the Program file (at the level of extensions maybe).

However, the real power would indicate customized names and tasking users (client partners helping development) to perform a certain task and evaluating the log after the fact. Then another task, but this time with this different twist -- indeed, you could "story-board" a whole series of scenarios with your client, and then task out the scenario, harvest the log and keep it as documentation. In this use case you would want to have WriteFileIfNoLog set to True so that the Log file shows only LoggingOn and LoggingOff steps when there were no Logs executed by proper functioning logic.

In this scenario one would most likely use the "SetLoggingPersistent(On)" feature. That is, a user "task" could involve a series of scripts performed in sequence as executed by an end user (enrolling a student from scratch) so you would want to only turn Persistent Off at the end of the entire task. You might even want to capture the work of a single user for a whole day (that is why all other logging features [other than LogSystemErrorsAutomatically] are dependent upon LogginOn and that could be within an If(UserAccount = "Sheila") block.

Here, when Logging is turned on and then set to Persistent, the logging would only turn off either when the system tells it to, specifically: LoggingOff, Persistent is turned off and that script finishes, or when FileMaker is closed (like when $$session variables go away).

Then, even after deployment, you can leave these (and/or add more strategically for deployment).

That is, I would think that Server would be able to evaluate all Log script steps, and execute them not only for users using Advanced, but for all users so that this can be an "ongoing debugger for a deployed application".

This is where the "email" parameter comes in. This feature would be inert unless the file where it is called is on the server and the server is configured to send emails. The "email" parameter itself could be a boolean expression where True sends to the Server configured email recipient. Groovier would be that it could be any expression that resolves to a valid email string (ideally either True or a valid email and True means "whatever email the server is set to"). In this use case you would set to WriteFileIfNoLog to False, otherwise you would have zillions of these -- indeed, you could have this overload to "False" when on the server (Log "Logging has been turned On" if you must).

The PayOff comes when that stray users decides to try some stray scenario that you hadn't accounted for -- you get a text message!

Deployment is also where you would want to use the LogSystemErrorsAutomatically. I would imagine that you would want both, but this can be used all by itself. That is it works with whatever Logging State is in place, but if called without any Logging State in place it would assume LoggingOn, it would assume Persistent Off, it would assume WriteFileIfNoLog False, and it would assume LoggingOff after the fact.

FWIW: $0.02

...wow, two cents seems cheap -- ah the power of coffee :-)

Edited February 25, 2010 by Guest