Re: OT: Design question

[Prior Nacre V]

Here's a possible way you might go about this using just two notionally singleton classes.

I haven't addressed data storage and retrieval, although I suspect a DB solution will prove the better choice. (%CFG represents the config data regardless of where and how it was read.)

I've also assumed $WID. This is expected to hold some unique reference to the widget being added.

Consider this as the basis of an approach to a solution rather than the solution itself. I've left it very skeletal as I don't know how this might fit into any existing framework you may have.

package Widget;

sub new
{
    my ($class, $rh_def_cfg) = @_;
    bless { rh_def_cfg => $rh_def_cfg, ro_event => Event->new } => $cl
+ass;
}

sub do_events
{
    my ($self, $WID) = @_;
    my $rh_event_data = $self->get_event_data($WID);
    foreach my $event (@{$rh_event_data->{events}})
    {
        $self->{ro_event}->$event($rh_event_data->{params});
    }
}

sub get_event_data
{
    # Use $WID to get type & widget
    # Use type to get parameters
    # Use widget to get events (based on type params)
    # Include other data to be used in Event class
    # Return hashref with event data
}


package Event;

sub new { my $class = shift; bless {} => $class }

sub email { ... }
sub log { ... }
sub trigger { ... }


package main;

my %CFG = get_cfg(); # DB or config file

my $ro_widget = Widget->new(\%CFG);

sub add_widget
{
    # Add here, then:
    $ro_widget->do_events($WID);
}

---

You might also consider an Aspect-Oriented solution. There's an Aspect module on CPAN which may be useful. (I don't know anything further about this module - others might).