Richard.
I'm not very experienced, but in my case it worked NOT to crowd all
the models into a single module. I'd recommend to have a main
db-access module and subclass it according to your different needs, as
you said here:
"Ideally I would move the WebApp::Model methods into their respective
WebApp::DB class (eg get_foo() goes into WebApp::DB::Foo), but then I
can't access it any longer from $c->param('model')->get_foo."
I guess that I'm missing something here, because I don't see why you
need to crowd all the models into a single one. You can still decouple
the models from the controllers if every subclass of WebApp::DB knows
how to interact with the database. Then, instead of
$c->param('mode')->get_foo();
you'll do:
my $foo = WebApp::DB::Foo->new;
$foo->get_all();
Where get_all is a sub inherited from WebApp::DB.
Also, the same way, you'll be able to use the get_all() in
WebApp::DB::Bar, WebApp::DB::Baz, etc;
Makes sense?
Julián Porta.
On Tue, Sep 23, 2008 at 9:36 AM, Richard Jones <[EMAIL PROTECTED]> wrote:
> I know we've been around here before in some related topics, but I would
> appreciate some feedback on a possible MVC structure for a Titanium/CGI::App
> that I am currently building.
>
> I'm using CA::Dispatch to allow multiple apps with a small number of rm's
> each. Views are handled by CAP::TT. Just the Model aspect is proving a
> little challenging. I'm trying to ensure that all database calls are handled
> outside the controllers, and to this end am using a module called
> WebApp::Model
>
> #####################
> package WebApp::Model;
>
> BEGIN {
> setmoduledirs('/path/to/app'); # Module::Find
> useall WebApp::DB; # Rose::DB::Object classes
> }
>
> sub new {
> my $class = shift;
> bless { }, $class;
> }
>
> sub get_foo { }
> sub update_bar { }
> sub delete_baz { }
> #####################
>
> WebApp::Model initially loads all WebApp::DB::* (Rose::DB::Object) classes,
> and is made available to the WebApp object via cgiapp_init:
>
> #################
> sub cgiapp_init {
> my $c = shift;
> ..
> $c->param( 'model' => WebApp::Model->new );
> }
> ################
>
> Each controller run-mode uses $c->param( 'model') to get its data:
>
> ######################################
> sub foo : Runmode { # CAP::AutoRunmode
> my $c = shift;
> ..
> my $data = $c->param('model')->get_foo;
> }
> ######################################
>
> This seems to work well, but the problem is that WebApp::Model is growing,
> as ever more (unrelated) db-related methods are added. Perhaps I
> could/should sub-class this one? Ideally I would move the WebApp::Model
> methods into their respective WebApp::DB class (eg get_foo() goes into
> WebApp::DB::Foo), but then I can't access it any longer from
> $c->param('model')->get_foo.
>
> But the main question is whether this is the right approach to start with -
> stuffing WebApp::Model into the WebApp object and retrieving it in the
> run-modes via a param_name. Advantages include decoupling the model from the
> controllers - they don't know/care how get_foo() gets its data, and I can
> change the db-related stuff (eg RDBO <=> DBIC) without affecting the
> controllers. Disadvantage (so far) is lumping all methods into one
> (WebApp::Model) module. Comments & thoughts most welcome.
> --
> 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/ ##
> ## ##
> ################################################################
>
>
##### 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/ ##
## ##
################################################################
