sub gimme_a_widget { my $event = shift; for my $handler (@event_handlers) { $handler->handle($event); } }
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:
I'm assuming all @event_handlers are classes and not objects, but if you need to you can replace that push statement withmy @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::$_"; } }
to create objects instead.push @event_handlers,"Handler::$_"->new();
Have fun.
Joost.
In reply to Re: OT: Design question
by Joost
in thread OT: Design question
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |