unknown
1970-01-01 00:00:00 UTC
And while this core exists in all Perl CGI modules, my experience is
that the controller of CGIP has captured it best. It prototypes the CGI
response cycle quite well.
On the other hand, I've never had a need for prototyped objects when
using CGIP - all my usage has basically been class-based and standard OO
and I've been pleased with the results.
.
I'd like to petition for a distinct module in the CGIP distro which uses
plain moose
<http://github.com/metaperl/perl-module-cgi-prototype/tree/master>.
If someone wants to implement something like that protomoose.t, then
that could be another module.
Further, I think CGIP would have been better received by the community
if the articles had pointed out exactly what prototype objects offer the
CGI application development process. Nothing I've seen in the standard
CGIP docs or Linux Magazine article
<http://www.stonehenge.com/merlyn/LinuxMag/col56.html> points to
something I could not do easily and cleanly with standard Moose (or
plain Perl) classes.
For instance my recent perlmonks praise of CGIP
<http://www.perlmonks.org/?node_id=786745> showed an example. But that
example benefitted from the controller cycle and standard OO dispatch.
--------------020703080408090805000909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Randal L. Schwartz wrote:<br>
<blockquote cite="mid:***@blue.stonehenge.com" type="cite">
<pre wrap="">Not really. The prototype stuff of Moose is where you want to start, and it
has a different interface. If you just pulled in Class::Prototyped, you'd
have a lot of potential conflicts, especially around anonymous classes.
</pre>
</blockquote>
I see. I'm not trying to anger you, but I would like to re-join our IRC
conversation. If
you read the CGIP docs, it speaks of 'the prototypical cgi application'
-<br>
<ul>
<li>Analyze the incoming parameters, cookies, and URLs to determine
the state of the application (let's call this "dispatch").</li>
<li>Based on the current state, analyze the incoming parameters to
respond to any form submitted ("respond").</li>
<li>
that the controller of CGIP has captured it best. It prototypes the CGI
response cycle quite well.
On the other hand, I've never had a need for prototyped objects when
using CGIP - all my usage has basically been class-based and standard OO
and I've been pleased with the results.
.
I'd like to petition for a distinct module in the CGIP distro which uses
plain moose
<http://github.com/metaperl/perl-module-cgi-prototype/tree/master>.
If someone wants to implement something like that protomoose.t, then
that could be another module.
Further, I think CGIP would have been better received by the community
if the articles had pointed out exactly what prototype objects offer the
CGI application development process. Nothing I've seen in the standard
CGIP docs or Linux Magazine article
<http://www.stonehenge.com/merlyn/LinuxMag/col56.html> points to
something I could not do easily and cleanly with standard Moose (or
plain Perl) classes.
For instance my recent perlmonks praise of CGIP
<http://www.perlmonks.org/?node_id=786745> showed an example. But that
example benefitted from the controller cycle and standard OO dispatch.
--------------020703080408090805000909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Randal L. Schwartz wrote:<br>
<blockquote cite="mid:***@blue.stonehenge.com" type="cite">
<pre wrap="">Not really. The prototype stuff of Moose is where you want to start, and it
has a different interface. If you just pulled in Class::Prototyped, you'd
have a lot of potential conflicts, especially around anonymous classes.
</pre>
</blockquote>
I see. I'm not trying to anger you, but I would like to re-join our IRC
conversation. If
you read the CGIP docs, it speaks of 'the prototypical cgi application'
-<br>
<ul>
<li>Analyze the incoming parameters, cookies, and URLs to determine
the state of the application (let's call this "dispatch").</li>
<li>Based on the current state, analyze the incoming parameters to
respond to any form submitted ("respond").</li>
<li>