[cgi-prototype-users] Prototyping CGI versus CGI::Prototype
Randal L. Schwartz wrote: 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. 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' - * Analyze the incoming parameters, cookies, and URLs to determine the state of the application (let's call this dispatch). * Based on the current state, analyze the incoming parameters to respond to any form submitted (respond). * From there, decide what response page should be generated, and produce it (render). 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. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] CGIP and eager loading of Template and CGI in mod_perl-like environments
On 10/29/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Randal L. Schwartz merlyn@stonehenge.com [2005-10-29 16:50]: You can probably automate that if you wanted.I'm sure you can come up with a BEGIN block that reads the directory and loads all the plugins.Cf. Module::Pluggable. Yes, also: http://search.cpan.org/~drolsky/Class-Factory-Util-1.6/lib/Class/Factory/Util.pm
Re: [cgi-prototype-users] Re: Tried to use My/App, unable to make it work
On 13 Oct 2005 04:58:39 -0700, Randal L. Schwartz merlyn@stonehenge.com wrote: For a better tiny app, see my Linux Magazine articles (google site:stonehenge.com CGI::Prototype for the location). That location is: http://www.stonehenge.com/merlyn/LinuxMag/col70.html and also 7[12].html --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
[cgi-prototype-users] Notes of moving a site from HTML::Mason to CGI::Prototype
I'm happy to say that HTML::Mason has been completely removed from my
personal website:
http://www.livingcosmos.org/
It was fairly easy to write a subclass of CGIP whose render phase took
an HTML file and templated it. I just needed a RewriteRule to push all
html files to the CGIP subclass:
RewriteRule ^/(.+)[.]s?html$ /cgi-bin/lc.cgi/$1.html [PT]
and then I used PATH_TRANSLATED to serve the HTML file:
sub dispatch {
my $self = shift;
my $p = $ENV{PATH_TRANSLATED};
$p =~ s!cgi-bin.+lc.cgi/!!;
$self-reflect-addSlot(file_path = $p);
$self-pkg_for_path($p) ;
}
sub pkg_for_path {
my ($self, $path) = @_;
my $M = Tie::RegexpHash-new;
$M-add( qr,vots/index.html, = 'App::vots' ) ;
if (my $new_page = $M-match($path)) {
eval require $new_page;
die $@ if $@;
warn 'NP', $new_page;
$new_page;
} else {
return $self;
}
}
--
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
cgi-prototype-users mailing list
cgi-prototype-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
[cgi-prototype-users] Re: each page is really an operation
A. Pagaltzis [EMAIL PROTECTED] writes: * Terrence Brannon [EMAIL PROTECTED] [2005-09-04 03:15]: To me, that means no cookies. But your discussion of 401 and 403 would imply such a mechanism for recognizing who made the request? I do (still?) use cookies. You are using a REST-inspired approach to web design, not pure REST: quote src=http://www.prescod.net/rest/state_transition.html; REST basically advises you choose between these two strategies: send all of the state back and forth (in this case using GET and URIs) or capture parts of the state as resources with URIs and transmit links to that state back and forth. What REST advises against is state without a URI name. COOKIES ARE AN EXAMPLE OF UN-REST-LIKE DATA. Cookes are implicit, so third parties have no access to them and even the client application will not typically have any way to know what cookies were in effect when a particular message was created hours ago. REST stands for REpresentational State Transfer - the constant transfer of state (or references to state) back and forth as representations are key to its design. /quote -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
[cgi-prototype-users] CGI::Prototype::PathInfo unified diff
requests to -Lmailto:[EMAIL PROTECTED], or through the web interface -at Lhttp://rt.cpan.org/. I will be notified, and then you'll automatically -be notified of progress on your bug as I make changes. +Please report any bugs or feature requests to the CGI::Prototype users mailing +list on Sourceforge (Lhttp://cgi-prototype.sf.net) +so that all 3 authors of the package (sourcemerlyn, apag, metaperl) can +be notified. =head1 AUTHOR Aristote Pagaltzis, Lmailto:[EMAIL PROTECTED] +contributions from Terrence Brannon and Randal Schwartz. + =head1 COPYRIGHT AND LICENSE Copyright (C) 2005 by Aristotle Pagaltzis [EMAIL PROTECTED]:~/perl/dl$ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
[cgi-prototype-users] content-type and content: do they deserve separation / methods
CGI::Prototype is remarkably flexible, scaleable and practical. That being the case, this is more of a philsophical question than any. However, it is a fact that for most websites, the content-type will be text/html for most of the pages and that the actual content will vary on each page. This being the case, should these two aspects of the CGI response be two different methods, with $self-content_type existing in a base class and re-used for most of the app and $self-content (which is known as $self-render) be variant on each page? -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
[cgi-prototype-users] each page is really an operation
While I'm having my philosophical catharsis, I thought I would mention that CGI::Prototype is actually not a page-based approach to site development. It is an operation-based approach. An operation consists of several phases which are broken down by CGIP nicely. We have model phases and view phases. The view phases create a page based on the requested *operation*. A user requests *operations* - login, add user, view user which are materialized by model actions and feedback on success failure via the view/page. If you take a look at Zanas: http://search.cpan.org/~dmow/Zanas-5.5.16/Zanas.pm he says a similar thing. -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
[cgi-prototype-users] Re: CGI::Prototype::PathInfo
A. Pagaltzis [EMAIL PROTECTED] writes: I suppose that Iâll stick with the current monolithic design and mind my own business for the time being, then. I'm also in need of using PathInfo to render pages on a dynamic site. Can you make the PathInfo stuff you are doing available on sourceforge or elsewhere? -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
[cgi-prototype-users] Re: CGI::Prototype::PathInfo
merlyn@stonehenge.com (Randal L. Schwartz) writes: A == A Pagaltzis [EMAIL PROTECTED] writes: A Now my question is: should I put this on CPAN, or should I leave A the space to an âofficialâ version? Or should I just post it A here, maybe? If I put this on CPAN myself, what should I put in A the AUTHOR and COPYRIGHT LICENSE sections of the POD? There is A so little code in there that the notion of authorship is a bit A ridiculous either way, but I also copied several pages of POD A that I can hardly claim authorship of. Well, if we create the SF archive, this can stay one or two distros. I'd actually like to see separate distros like: I have added Aristotle (sf.net id: apag) as a developer with plenty of liberal admin rights to the whole project - let me know if you need more. I couldn't find Randal Schwartz in the sf.net user list and someone has the name merlyn already. Right now, it looks like Aristotle needs the privs more than Randal, but as soon as I get his name, I will heap on lots of privs for him as well. Yes, as soon as this PathInfo baby gets uploaded, I can de-Mason-ize a site of mine with the greatest of ease :) -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] Re: CGI::Prototype::PathInfo
merlyn@stonehenge.com (Randal L. Schwartz) writes: Terrence == Terrence Brannon [EMAIL PROTECTED] writes: Terrence I have added Aristotle (sf.net id: apag) as a developer with Terrence plenty of liberal admin rights to the whole project - let me Terrence know if you need more. I couldn't find Randal Schwartz in Terrence the sf.net user list and someone has the name merlyn Terrence already. I'm sourcemerlyn there. added: https://sourceforge.net/projects/cgi-prototype/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
