Hi Sherzod --
> Jesse, first of all, thanks a lot for the chartexample.cgi and
> ChartExample.pm examples. I appreciate your time. It is a well-written
> library.
Thanks!
> It works perfectly when one uses functions in the run_modes().
>
> But most of my robust sites have been developed in Object Oriented Perl.
> For examle, in my helpdesk application I am working on currently, I
> have a class called HD::Deparment and I use it something like following:
>
> # gets the DBI instance
> my $dep = new HD::Department($dbh);
>
> if ( $cmd eq "list" ) {
> $body .= $dep->return_list($cgi);
> } elsif ( $cmd eq "delte" ) {
> $body .= $dep->delete($cgi->param('id'));
> } elsif ( $cmd eq "modify" ) {
> $body .= $dep->update($cgi);
> }
>
> $dep->save();
>
> print Body($cgi, $dbh, $body, $session);
>
> .................
>
>
> You see, those run_modes() can't use my methods, no way.
> So does it mean that I have to write seperate functions
> for calling those methods?
Writing separate run-mode methods to proxy the functions in your
HD::Department module is definitely one valid way to handle this. This type
of module is often referred to as a "controller" module (from the
"Model/View/Controller" design pattern), and is a principle use of
CGI::Application. A "controller" solution might look like this:
package HD::Department::Controller;
use base "CGI::Application";
use HD::Department;
sub setup {
my $self = shift;
$self->run_modes(
"list" => "return_list",
"delete" => "delete",
"modify" => "update",
);
$self->start_mode("list");
my $dbh;
$self->param("dep" => HD::Department->new($dbh));
}
sub teardown {
my $self = shift;
my $dep = $self->param("dep");
$dep->save();
}
sub return_list {
my $self = shift;
my $cgi = $self->query();
my $dep = $self->param("dep");
return $dep->return_list($cgi);
}
# Other methods are written similarly...
OTOH, it looks like your module HD::Department really performs quite a lot
of CGI functions (reading query params, building and returning HTML). An
even quicker way of dealing with this might be to just make HD::Department
and subclass of CGI::Application. In that case, all your functions *would*
be called as methods, by CGI::Application.
Besides adding the setup() and teardown() methods to HD::Department, you
would have to modify its methods to retrieve the $cgi object from the
query() method, instead of receiving it as an argument. Other than that,
I'd bet that it would be a very simple change. (As I mentioned before, your
coding style is very compatible with CGI::Application.)
IMHO: If you choose to write a "controller" module to proxy calls to
HD::Department it would be very beneficial to modify HD::Department to work
entirely independent of the CGI query. HD::Department methods should take
parameters as arguments, instead of expecting a CGI query object.
HD::Department methods should return structured data, instead of HTML.
These changes will make HD::Department entirely free from CGI-specific
behaviors so that non-web applications (a cron process, for instance) can
use HD::Department. Your new "controller" module would transform the CGI
query into parameters, and resultant data into HTML. HD::Department would
become much more of a pure "model" module, and could be reused more
extensively. (Just a suggestion!)
Warmest regards,
-Jesse-
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
