[cgiapp] Seeking code review on CGI::Application::Model
NP Bamber
np.bamber at ntlworld.com
Fri Aug 14 17:47:56 EDT 2009
I take it from the fact that my previous email did not get a response
that everyone thought/hoped I would go away. If so I quite understand --
you must all have seen similar messages millions of times - especially
from people you have never heard of. However this was an itch that did
not go away. I have got something that could be uploaded into PAUSE
although I will produce another version and fix a few minor issues
before I do so. Based upon my testing on a private apache server I am
really excited that this is the way forward for me and that it fills a
big hole. Also it attempts to achieve only a small but important role
and I believe I have been careful not to cut off any possible use of
other modules - including some that I am not intending to use myself.
The three modules are:
CGI::Application::Model (a base class)
CGI::Application::Model::DBI (a specific implementation)
CGI::Application::Plugin::Model (integrates the above classes into
CGI::Application)
To summarise what the modules do I would use them as follows. I assume
that CGI::Application::Dispatch wildcards most urls into a single run
mode with a $modelid parameter as follows:
'*' => {app=>'MainApp',rm=>'model','*'=>'modelid'}
In the setup function the "model" is configured with the help of
CGI::Application::Plugin::DBH and the "model" run mode is mapped on to
the "model_driven" function which has the following code
sub model_driven {
my $c = shift;
return $c->model_load_tmpl($c->param('modelid'))->output;
}
What this "model_load_tmpl" function is does is given a "model id" it
looks up the template and the parameter data hash from a database and
stuffs the latter into the former. The "model" runmode assumes that no
other parameters need to be filled but other run modes might take
responsibility for certain template parameters. My current contract is
for a website that needs to be in three languages. So essentially the
templates can contain no text and all of it must be drawn from the
database whilst the HTML structure must be reused. From my experiments
so far this is working really well.
Given the juicy bit of CPAN real-estate I am looking to claim, I would
really appreciate it if someone would agree to code review this. I can
send the tar files by email (about 20K in total), post a long message on
http://perlmonks.org, upload them to PAUSE putting aside any name space
issues or whatever method would be most desirable.
cgiapp-request at lists.openlib.org wrote:
> Send cgiapp mailing list submissions to
> cgiapp at lists.openlib.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openlib.org/mailman/listinfo/cgiapp
> or, via email, send a message with subject or body 'help' to
> cgiapp-request at lists.openlib.org
>
> You can reach the person managing the list at
> cgiapp-owner at lists.openlib.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cgiapp digest..."
>
>
> Today's Topics:
>
> 1. I am thinking of writing a "Model" class for the
> CGI::Application (NP Bamber)
> 2. Re: RunmodeDeclare and ValidateRM incompatibility? (Ron Savage)
> 3. Re: RunmodeDeclare and ValidateRM incompatibility? (Richard Jones)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 18 Jun 2009 19:23:55 +0100
> From: NP Bamber <np.bamber at ntlworld.com>
> Subject: [cgiapp] I am thinking of writing a "Model" class for the
> CGI::Application
> To: cgiapp at lists.openlib.org
> Message-ID: <4A3A863B.7070603 at ntlworld.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I have been using CGI::Application/HTML::Template for a while now and I
> like the feeling that the code base is small enough that I can master
> its internals. However I am finding that all my code needs refactoring
> for various reasons and I need something more like a "content management
> system". I do think I should learn "catalyst" if only for professional
> reasons however I would like to continue using the Titanium framework. I
> believe I can see an approach that would not require a lot of work, but
> would allow me to push some of my data structures (particularly
> metadata) out of perl and into a database. I have managed to extract
> from my head the following manifesto:
>
> The L<Titanium> framework does a reasonable job of the controller
> part of the model-view-controller concept of web site
> architecture. Various
> template modules, for example L<HTML::Template> can function as
> the view part and they are well
> integrated with our controller. There are various candidates for a
> model class, for example
> L<DBIx::Class>. Another part of the Titanium framework,
> L<CGI::Application::Dispatch> can be used to translate
> from search engine friendly URLs to a database key - in fact the
> wildcard parameter provided by the
> Dispatch fall-through rule will do nicely. All that is missing is
> a perl module to take the Dispatch wildcard,
> pull the template file name and the various template parameters
> from the database and in a standard run
> mode stuff the parameters into the template. This class provides
> the abstract base, that will be
> derived from by classes such as
> L<CGI::Application::Model::DBIx-Class>. For particular processes such
> as form processing non-standard run
> modes might be returned from the database. The standard run mode
> for processing off the database is installed
> by the class L<CGI::Application::Plugin::Model> and this module
> will also instantiate the module object. Keeping a list of pages on
> a database enables other finctionality provided by the classes
> L<CGI::Application::Plugin::Sitemap>,
> L<CGI::Application::Plugin::RSS> and
> L<CGI::Application::Plugin::Search>.
>
> I can also see only one candidate for an alternative in the existing
> CPAN archive. That would be to represent "web pages" as objects using
> the Class::DBI and feed them into the template using the dot notation.
> However this seems to me to commit one to usage of Class::DBI (which
> there should be no commitment to any database encapsulation layer) and
> maybe it is entangling the view and model parts. Advice, correction or
> encouragement please.
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 19 Jun 2009 09:57:09 +1000
> From: Ron Savage <ron at savage.net.au>
> Subject: Re: [cgiapp] RunmodeDeclare and ValidateRM incompatibility?
> To: CGI Application <cgiapp at lists.openlib.org>
> Message-ID: <1245369429.3956.231.camel at zoe.savage.net.au>
> Content-Type: text/plain
>
> Hi Richard
>
> On Thu, 2009-06-18 at 09:31 +0100, Richard Jones wrote:
>
>> Rhesa Rozendaal wrote:
>>
>>
>>>> It was designed to just get OP (Original Poster) to re-think /his/ line
>>>> of attack :-).
>>>>
>>> Good point. At the very least it prompted me to suggest yet another
>>> approach.
>>> Ar you still with us, Richard? :-)
>>>
>> Wasn't then (02:52 GMT) - am now. It's true I've had a few issues with
>>
>
> Just in case you think I'm a night owl too, it was 11:09 am when I
> posted... That's what you get for being at the center of internet, aka
> Melbourne, Australia :-).
>
>
>> RunmodeDeclare in the past, but always because I've misused it. Your
>> suggestion not to use signatures on run modes and to fetch query params
>> traditionally, or alternatively only declare positional arguments, are
>> both consistent with maintainability IMO, provided it's documented
>> locally in the application, so I can remember how it works when I come
>> back to it in future. That's really the issue here I think -
>> understanding (and remembering) how RunmodeDeclare (and
>> Method::Signatures) actually works.
>>
>> So in answer to Ron's nuclear option, I'm not persuaded it's necessary
>> to bin it at the moment. But in reality I use it only for the admin
>> parts of my app, as it was too much work to re-factor all the rest of it
>> away from AutoRunmode, which was and is working fine anyway.
>>
>
> Fair enough. I'm deeply uneasy about adding these modules on top of
> things, myself, so I don't.
>
>
More information about the cgiapp
mailing list