CGI Development - Multiple Entry or Dispatch

David Dick david_dick at iprimus.com.au
Mon Nov 4 12:49:30 CST 2002


Joshua Goodall wrote:

>On Mon, Nov 04, 2002 at 10:01:07AM +1100, Scott Penrose wrote:
>  
>
>>dispatch.cgi
>>------------
>>
>>	use MyImplementation;
>>	my $m = MyImplementation-new();
>>
>>	if ($ENV{PATH_INFO} eq "") {
>>		$m->view;
>>	} elsif ($ENV{PATH_INFO} eq "edit") {
>>		$m->edit;
>>	} elsif ($ENV{PATH_INFO} eq "save") {
>>		$m->save;
>>	} else {
>>		$m->error;
>>	}
>>    
>>
>
>This seems more maintainable to me. You could even abstract it
>(validation notwithstanding):
>
>	use MyImplementation;
>	use CGI;
>
>	my $m = new MyImplementation;
>	my $q = new CGI;
>	my $p = $ENV{PATH_INFO};
>
>	$m->$p($q) if $m->publicmethod($p);
>
>This turns the request into a facade for invocation of a method
>on a visited object.  OO pattern freaks please note :)
>
>This is not unlike the container model of a J2EE server, although
>without any of the sophistication (resource/instance pooling etc).
>
where does J2EE implement this sort of stuff? I always imagined that 
instance pooling would be handled by a some sort of proxy thingy 
inbetween the script and MyImplementation method, like

my $m = proxy_new MyImplementation;

to allow for the pooling to be used by cron jobs for example.  Or am i 
completely off the wall here?

>If MyImplementation is autosplit, then neither approach needs much
>compilation.
>
>The dispatch model also allows MyImplementation to be a completely
>remote process.  In the multiple methods model, you're constrained
>to only implementing remote methods known in advance.
>
i would argue that can be a strength of multiple methods.  It forces a 
private vs public methods implementation, and stops a later developer 
from blowing a hole in the application by developing 
MyImplemention->admin_function() only to find out that without his/her 
knowledge, it's become a function available to anyone with a web browser.

>Not many people need such separation, of course.  I think ultimately
>only very large or complex OO systems benefit (in maintainability)
>from strict pattern usage.  Everything else seems to fall into the
>category of "whatever seems most appropriate at the time".
>
>Joshua
>
>  
>




More information about the Melbourne-pm mailing list