I'm confused about names. I would describe the activity you are modelling as "an event triggers an action". In that terminology the "event" is "add a widget to the database"; the long if/elsif statement you're trying to replace is then a combination of the triggers and actions.

If I understand your description so far, you are conceptually combining the trigger and the action into a single item, and planning to have a class for each combination of type-of-trigger and type-of-action. If so, consider separating the two to reduce the number of classes you have to deal with.

Beyond that, both trigger and action are in principle a coderef, one that makes a decision (no side effects, returns a boolean), and one that does something (all about the side effects, returns nothing or maybe a failure code). You can probably reduce those to a small set of simple components and a small set of combining rules, like:

  Trigger::property_is ( property_name, value )
    returns true if the widget has property I<property_name> equal to 
+I<value>

  Trigger::and ( trigger1, trigger2 )
    returns true if both trigger1 and trigger2 are true

  Action::email ( address, template )
    fills in I<template> and emails the resulting text to I<address>

  Action::also ( action1, action2 )
    performs I<action1>, and if successful also performs I<action2>

  etc.
[download]

This can all readily be modelled by a small domain-specific language that will make the configuration nice and easy to read and write.

However for the numbers you're talking about I'd want to store these things in a database and start thinking about tools to interrogate and act on subsets of the triggers as a whole, and this is where it gets tricky - I've never yet found a good solution to modelling this type of information in a database, in particular where you have lots of similarish functions that nevertheless can take different numbers of parameters, or different types of parameters, or parameters (such as 'value' in the first example above) whose type can only be derived by a complex process (looking up the type of the 'property_name' property).

Anyone got a polymorphic database field type handy?

Hugo