class layout ... not sure i'm doing the right thing

geektron has asked for the wisdom of the Perl Monks concerning the following question:

i'm adding a new workflow to an app that does some really strange things ... and i'm trying to come up with a class stucture that i can graft in with the least amount of pain.

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:

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();
}
[download]

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 ...

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 ...

Comment on class layout ... not sure i'm doing the right thing Select or Download Code

Replies are listed 'Best First'.
Re: class layout ... not sure i'm doing the right thing by merlyn (Sage) on Jun 10, 2005 at 21:34 UTC
If CGI::Application doesn't exactly cut it for you, see if CGI::Prototype is flexible enough. That was the boat I was in, and now I'm floating along! -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^2: class layout ... not sure i'm doing the right thing by geektron (Curate) on Jun 10, 2005 at 21:38 UTC
i remember CGI::Prototype being pointed out one other time, but i can't remember what kept me away from it.	[reply]
Re^2: class layout ... not sure i'm doing the right thing by geektron (Curate) on Jun 11, 2005 at 19:33 UTC
not sure it matters, but now that i go back and read the CGI::Prototype docs, i know why i can't use it. i'm 'required' to use HTML::Template, and i really don't want to try and create an app that's a hybrid of HTML::Template and Template::Toolkit	[reply]
Re^3: class layout ... not sure i'm doing the right thing by merlyn (Sage) on Jun 11, 2005 at 21:03 UTC
So, override ->render to do whatever you want. The whole point of CGI::Prototype is that it's subclassable. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]