Re: OT: Design question

Your names are confusing to me. In my eyes, assuming that the only thing that really determines the event and its parameters is the widget, the widget is the event. So let's call the widget $event, and the events event_handlers. What I would try to make is a main handler like this:

sub gimme_a_widget {
 my $event = shift;
 for my $handler (@event_handlers) {
   $handler->handle($event);
 }
}
[download]

As you can see the main code doesn't actually try to do anything with the innards of either $event or $handler. I'm just making the easiest interface I can think of, and I'm trying to keep all the implementation details out of the main code.

Now @event_handlers can contain objects or classes, or a mix of both, it doesn't matter, as long as each of them has a handle() method that accepts an $event (or $widget, if you prefer) parameter.

This makes the @event_handlers themselves responsible for parsing and processing the widget. You probably don't want to copy a lot of similar code to all the different event_handlers, so the $handler classes can inherit from some base class if that seems useful, or they can share code by calling to some other class. (update: or they can be objects of the same class, as demonstrated further on in the thread)

As for setting up the classes, let's say all event_handler classes are named Handler::SomethingOrOther, and you put each in its own SomethingOrOther.pm file in the /my/event/handlers/Handler directory:

my @event_handlers;
BEGIN {
  my $dir = '/my/event/handlers';
  use lib $dir;
  for (</my/event/handlers/Handler/*.pm>) {
    s#.*/##;
    s#\.pm$//;
    eval "use Handler::$_;" or die $@;
    push @event_handlers,"Handler::$_";
  }
}
[download]

I'm assuming all @event_handlers are classes and not objects, but if you need to you can replace that push statement with

   push @event_handlers,"Handler::$_"->new();
[download]

to create objects instead.

Have fun.

Joost.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re: OT: Design question Select or Download Code

Replies are listed 'Best First'.
Re^2: OT: Design question by dragonchild (Archbishop) on Sep 30, 2004 at 18:21 UTC
I'm with you so far. The problem I'm having is the maintenance of hundreds of event_handlers (to use your terminology). So, your plan would be to have potentially hundreds of classes in the Handlers directory. However, most of the handlers will be almost exactly the same, differing only minor details. For example, the Handler::GreenWidget emails to green2341@place.com and Handler::BlueWidget emails to blue238882@place.com. And, so on for 80 colors. Now, if I put this in a config file, how do I handle that? Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]
Re^3: OT: Design question by Joost (Canon) on Sep 30, 2004 at 18:33 UTC
Ok, well in that case you could have a Handler::Colors that has returns those 80 objects from its new() method (though I would probably call it something else, then, like init()): package Handler::Colors; use YAML qw(Load); # or some other module to handle config-like files # set up a bunch of event handlers that # send email depending on colour sub init { my $colors = Load('/color/config'); my @handlers; while (my ($color,$email) = each %$colors) { @handlers = Handler::Colors->new( { color => $color, email => $email } ); } return @handlers; #update: added this line! } # create handler object sub new { my $class = shift; return bless { @_ },$class; } # check for my color and send email if found. sub handle { my ($self,$event) = @_; if ($self->{color} eq $event->color()) { send_mail($self->{email}); } } [download] updated: added return @handlers line update2: To clarify: this code plugs into the code in my post above, so you can have more of these classes for each different type of action you need to perform. All that's changed there is that the `push @event_handlers,"Handler::$_";` [download] line needs to be replaced by `push @event_handlers,"Handler::$_"->init();` [download] "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l] [select]
Re^4: OT: Design question by dragonchild (Archbishop) on Sep 30, 2004 at 19:05 UTC
Ok. That's the design twist I was looking for - different config files for each kind of event handler. THANK YOU! :-) Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]
Re^3: OT: Design question by uwevoelker (Pilgrim) on Oct 02, 2004 at 14:22 UTC
> For example, the Handler::GreenWidget emails to > green2341@place.com and Handler::BlueWidget emails to > blue238882@place.com. And, so on for 80 colors. If you write a base class Handler::Email and within Handler::GreenWidget you do: `use base 'Handler::Email'; sub email { 'green2341@place.com' }` [download] And in Handler::Email you do: `sub handle { my $email = $self->email; # send email # ... }` [download] I think you get the point. So you don't have to duplicate similar code.	[reply] [d/l] [select]


laziness, impatience, and hubris
	PerlMonks