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.
[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/ ##
## ##
################################################################
