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.
[email protected] wrote:
Send cgiapp mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
Subject: [cgiapp] I am thinking of writing a "Model" class for the
CGI::Application
To: [email protected]
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: [cgiapp] RunmodeDeclare and ValidateRM incompatibility?
To: CGI Application <[email protected]>
Message-ID: <[email protected]>
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/ ##
## ##
################################################################
