i *thought* that a GOF Facade pattern would do nicely, since the app in question forces everything to run through a sub display() that's called by the mod_perl handler.
the new workflow is multi-step, so i could possibly use CGI::App for this, but the logic re: deciding which class in next to instantiate seems a little more complicated than CGI::App currently handles.
this is what i came up with ... but i implemented this once before, and frankly was not happy with the kludgey "switch" statement:
ConferenceBuilder.pm
facade class, responsible for dispatching requests to the appropriate 'child' class.
+ new() -- the usual constructor
+ display() -- called by the mod_perl handler
+ getChildClass -- called within display() using the parameters passed in
+ storageNeeded() -- check and see if a DB update is needed
Foundation.pm
one of the "child" classes. each class is really only related as a step of the process .. this particular one is step 1 of 5
+ new() - constructor
+ buildPage - builds HMTL page based on templates and data from other smaller classes
+ store() - stash the needed stuff in the database.
sub ConferenceBuilder::display() would roughly be:
one problem with this is that it doesn't have any "re-entrance".... the user won't be sent back a page if there's an error on storage ...sub display { my ( $self, %params ) = @_; my $childClass = $self->getChildClass( %params ); my $obj = $childClass->new( %params ); $obj->store() if ( $self->needsStorage ( $childClass, %params ) ); return $childClass->buildPage(); }
my previous implementation (from some time back) involved a named block that returned a pair of class names, the current and the next ... so that if storage worked out, the next class was invoked. that just seems really clunky.
i know this is a problem that's been solved before ...
In reply to class layout ... not sure i'm doing the right thing by geektron
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |