Seeking code review on CGI::Application::Model
|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Seeking code review on CGI::Application::Model
by NP Bamber
::
Rate this Message:
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@... wrote: >> Send cgiapp mailing list submissions to >> cgiapp@... >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://www.erlbaum.net/mailman/listinfo/cgiapp >> or, via email, send a message with subject or body 'help' to >> cgiapp-request@... >> >> You can reach the person managing the list at >> cgiapp-owner@... >> >> 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@...> >> Subject: [cgiapp] I am thinking of writing a "Model" class for the >> CGI::Application >> To: cgiapp@... >> Message-ID: <4A3A863B.7070603@...> >> 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@...> >> Subject: Re: [cgiapp] RunmodeDeclare and ValidateRM incompatibility? >> To: CGI Application <cgiapp@...> >> Message-ID: <1245369429.3956.231.camel@...> >> 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. >> >> > ##### 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/ ## ## ## ################################################################ |
| Free embeddable forum powered by Nabble | Forum Help |
