[cgiapp] Re: Seeking code review on CGI::Application::Model
NP Bamber
np.bamber at ntlworld.com
Fri Aug 14 18:01:17 EDT 2009
Actually the easiest thing was for me to put the files directly on the
internet (temporarily).
http://download.periapt.co.uk/CGI-Application-Model-0.01.tar.gz
http://download.periapt.co.uk/CGI-Application-Model-DBI-0.01.tar.gz
http://download.periapt.co.uk/CGI-Application-Plugin-Model-0.01.tar.gz
NP Bamber wrote:
> 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