Brad Van Sickle wrote:
[ .. ]
Currently, I'm working on creating a content management system for a
static website. The CMS has quite a few sections (manage users, manage
events, manage articles, etc... ) but each section does basically the
same things (displays the current records, allows you to delete or edit
current records, allows you to create a new record) Right now I have it
set up so each section is it's own application. I have an instance
script and a package for each section. Within that package I change out
the SQL statements and related code, load different templates for the
create/edit forms, etc... It works well, but I'm not sure that this is
the "right" way of doing things.
It seems to me that there is probably a way to do this by using a
different instance script for each section, but having them all leverage
the same package by initializing it with section specific data on the
forms and SQL statements, and than adding in subclasses or instance
script code for any additional methods that may be required... but I'm
still kind of new with OO PERL and I can't quite wrap my head around the
details.
Another way to approach this is to use CGI::Application::Dispatch, and
revert to a single instance script pointing to your Dispatch class, and
let *it* load the relevant controller class. That way you can have an
integrated application with many separate components, for example -
using the MVC approach - UserManager, EventManager, ArticleManager
controller classes. So something like the following would do it:
# myapp.cgi:
use MyApp::Dispatch;
MyApp::Dispatch->dispatch();
# MyApp::Dispatch:
use base 'CGI::Application::Dispatch';
my @config_files = map { '/path/to/app/root/config/' . $_ }
$d->read; # where $d = IO::Dir->new('/path/to/app/root/config')
sub dispatch_args {
return {
prefix => 'MyApp',
table => [
'/' => { app => 'YourDefaultController', rm => 'default_rm' },
# specific matches (optional):
'admin/:app' => { prefix => 'MyApp::C::Admin' },
'admin/:app/:rm' => { prefix => 'MyApp::C::Admin' },
'admin/:app/:rm/:id'=> { prefix => 'MyApp::C::Admin' },
# generic matches:
':app' => { }, # MyApp::C::* - uses default runmode
':app/:rm' => { }, # MyApp::C::* - uses specified runmode
':app/:rm/:id' => { }, # captures 'id' in $self->param('id')
],
args_to_new => {
PARAMS => {
config_files => \...@config_files,
},
}
}
# MyApp:Controller::UserManager
use base 'MyApp::Base';
sub default_runmode { ..}
sub display_users { .. }
sub delete_user { .. }
etc
# MyApp::Base # you could put common methods in here eg create
# record, delete record, etc
use base 'CGI::Application';
use CGI::Application::Plugin::TT;
use CGI::Application::Plugin::Session;
etc
Note, I've used 'C' instead of Controller in the dispatch_args() table
definition to save it line-wrapping. See:
http://search.cpan.org/~markstos/CGI-Application-Dispatch-2.16/lib/CGI/Application/Dispatch.pm
for more details.
CAD also works well in mod_perl & fastcgi environments, and also when
using CGI::Application::Server for development.
> Coding that class to handle dynamically passed SQL statements
> and process dynamic forms seems very very difficult to me.
This is where ORM's such as DBIx::Class and Rose come in very useful as
your 'Model' in the MVC architecture, but that's a subject for another time.
--
Richard Jones
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
