A Simple Naming and Logging Convention for Memento Triggers

25 views
Skip to first unread message

Flaviano

unread,
Jul 25, 2026, 11:12:48 AMJul 25
to mementodatabase

Hi everyone,

While debugging some complex Memento Database libraries, I realized that one thing I was missing was a simple and consistent way to identify exactly which trigger was running and when it started and finished.

In Memento, a trigger is defined by a combination of two selections: an Event and a Phase. While this makes each trigger easy to identify, the resulting description can be quite long. In addition, several phases have the same name (such as "Before saving the entry") and only differ by their associated event.

So I came up with a small naming convention that assigns a unique three-letter abbreviation to each Event/Phase combination.

The convention is completely optional, of course. The main goal is simply to make logs easier to read and to identify the execution flow at a glance.

The idea is to use two levels of naming:

  • A short name for the trigger script itself (CEO, CEB, UEO, etc.).

  • A descriptive meaning used only in documentation and log messages (Creating Entry Opening, Creating Entry Before Save, etc.).

This keeps the trigger list clean and compact while still producing self-explanatory log messages.

For example:

Official trigger:
Creating an entry → Opening an Entry Edit card

Suggested trigger name:
CEO

Meaning:
Creating Entry Opening


Then, at the very beginning of the trigger, I add:

log("===== <CEO = Creating Entry Opening> =====");

And at the very end:

log("===== </CEO = Creating Entry Opening> =====");

I repeat the same pattern for every trigger.

The three-letter abbreviations also follow a simple and consistent pattern:

  • First letter: the action (Creating, Updating, Deleting or Opening)

  • Second letter: the object (Library, Entry or Field)

  • Third letter: the execution phase (Opening, Before or After)

The exact meaning of the third letter depends on the trigger. For example, B may stand for Before Display, Before Save, or Before Delete, while A may stand for After Display, After Save, or After Delete.

Once you know the pattern, the abbreviations become easy to remember and immediately convey what each trigger does.

Here are the abbreviations I currently use:

  • CEO = Creating Entry Opening

  • CEB = Creating Entry Before Save

  • CEA = Creating Entry After Save

  • UEO = Updating Entry Opening

  • UEB = Updating Entry Before Save

  • UEA = Updating Entry After Save

  • DEB = Deleting Entry Before Delete

  • DEA = Deleting Entry After Delete

  • UFB = Updating Field Before Save

  • UFA = Updating Field After Save

  • OEB = Opening Entry Before Display

  • OEA = Opening Entry After Display

  • OLB = Opening Library Before Display

  • OLA = Opening Library After Display


The result is a log that mirrors the user's interaction with the application. As I read the log, I can follow the exact sequence of events—from opening a library, to viewing an entry, editing it, validating it, and finally saving it.

For example, a log may look like this:

===== <OLA = Opening Library After Display> =====
Library opened successfully.
===== </OLA = Opening Library After Display> =====

===== <OEB = Opening Entry Before Display> =====
===== </OEB = Opening Entry Before Display> =====

===== <OEA = Opening Entry After Display> =====
===== </OEA = Opening Entry After Display> =====

===== <UEO = Updating Entry Opening> =====
===== </UEO = Updating Entry Opening> =====

===== <UEB = Updating Entry Before Save> =====
Validating mandatory fields...
Checking references...
Saving changes...
===== </UEB = Updating Entry Before Save> =====

===== <UEA = Updating Entry After Save> =====
Refreshing linked entries...
===== </UEA = Updating Entry After Save> =====


I know this is a very small convention, but I've found it helpful when debugging larger libraries with many triggers.

Another benefit is that the trigger list itself remains very compact. In my libraries, the trigger scripts are simply named CEO, CEB, UEO, UEB, etc., which makes the trigger tree much cleaner and easier to scan.

Maybe some of you will find this useful as well.

If you've adopted a different naming or logging convention for your triggers, I'd be interested to hear about it.

Flaviano

Flaviano

unread,
Jul 25, 2026, 11:30:25 AMJul 25
to mementodatabase
Regarding the previous message, I am attaching two example images. On the log screen, the scripts named "Script" refer to Widgets. I am not sure if there is a way to name them as well.
Trigger names.jpg
Log example.jpg
Reply all
Reply to author
Forward
0 new messages