[cgiapp] thread on CGI::Application run modes, form validation, and objectcomposition

2003-08-04 Thread Richard Dice
: playing around with CGI::Application for the first time... Date: Fri, 01 Aug 2003 15:32:17 -0400 From: Richard Dice [EMAIL PROTECTED] To: [EMAIL PROTECTED] Jesse: Hello again... I hope all has been well with you... So, I'm web programming again. *sigh* :-) It's a temporary gig until the 2nd

Re: [cgiapp] Form paragraph

2003-08-25 Thread Richard Dice
Whippo, Ryan K wrote: I have a form paragraph that once it has more than 1975 characters in it, the submit button on the form will not work. Any ideas? Are you using the GET method to submit your form? (i.e. via the URL and the QUERY_STRING environment variable) I thought that that was

[cgiapp] list for TMPL_PATH

2003-09-03 Thread Richard Dice
Hello everyone... I was wondering if there was a way to specify a list of paths for the template provided by -load_tmpl to search view the TMPL_PATH in -new. E.g. my $webapp = MyApp-new( TMPL_PATH = [ '../apptmpls/MyApp',

Re: [cgiapp] directory structure and static pages

2003-09-04 Thread Richard Dice
Andy Taylor wrote: I'm getting ready to start a fairly large project using CGI::App and I was just wondering how some of the more experienced/knowledgeable people on this list handle some issues. 1. if you are doing a project with a superclass and several modules, where do you put your templates

Re: [cgiapp] Explicitly declaring the AUTOLOAD runmode

2003-09-05 Thread Richard Dice
a little because it's not really one of my VALID run modes, but declaring it with $self-run_modes() means that if someone calls my app with rm=AUTOLOAD CGI::App thinks it's a valid run-mode. If someone calls your run mode? Isn't the programmer the one who sets up the rm= URL or form query info?

Re: [cgiapp] Writing the CGI::Application book

2004-01-22 Thread Richard Dice
This is a really good idea. I've got a number of editors, publishers, agents, etc. in my Rolodex (well, Palm) -- the bounty of having written a number of books already over the past few years. It wouldn't be hard to sell this idea. Jesse, whaddaya think? Sam, you on this list? :-)

Re: [cgiapp] Re: Writing the CGI::Application book

2004-01-22 Thread Richard Dice
Mark: There's a lot to reply to in your email, and not enough time on my part to do so. I'll just hit a few quick points here... I don't think we have be exclusive about the modules that we choose to mention. While there are may be favorite, recommended or popular modules to include, partly

Re: [cgiapp] Re: Writing the CGI::Application book

2004-01-25 Thread Richard Dice
John: Thanks for chiming in here. I hope that you enjoyed the talk I gave at Toronto.pm a few months ago on this topic and that it inspired you to come out for some more. :-) Excellent point. However (as a one time publisher! and sometime tech writer) it is necessary to be very clear as to

Re: [cgiapp] Re: Writing the CGI::Application book

2004-01-25 Thread Richard Dice
Regarding my suggestion that Class::DBI is preferable to raw SQL DBI in a large scale complicated web app project, Sam said: I honestly couldn't disagree more. [deletia] Class::DBI could indeed be underpowered to handle the kind of complicated cases that you describe. [ Could Tangram be the

Re: [cgiapp] Reloading C::A in modperl

2004-01-27 Thread Richard Dice
Before I send it to mod_perl list I put it here because the problem mainly concerns C::A. No, not really. To the degree that you are having problems with Apache::Reload, this is a mod_perl/Apache::Reload problem. But the problem that the error message you gave us pertains to a basic Perl

Re: [cgiapp] Param method?

2005-07-04 Thread Richard Dice
I'm not arguing whether setter/getters are good or bad. Just why I'm forced to use C::A's. Why is that the only way to avoid stepping on C::A's variables? It sounds like you want to rewrite the contract. Currently, the contract states if you use the param method and its implicit get/set

Re: [cgiapp] Param method?

2005-07-04 Thread Richard Dice
I agree with that if I'm acessing C::A's underlying data structure. What I'm getting at is why does C::A force its underlying data structure upon me? Shouldn't I be able to access $self any way I want? Shouldn't there be a way to prevent me from stepping on C::A's data structure without

[cgiapp] [Fwd: CPAN Upload: R/RD/RDICE/CGI-Application-Framework-0.22.tar.gz]

2005-09-13 Thread Richard Dice
@perl.org To: Richard Dice [EMAIL PROTECTED] The uploaded file CGI-Application-Framework-0.22.tar.gz has entered CPAN as file: $CPAN/authors/id/R/RD/RDICE/CGI-Application-Framework-0.22.tar.gz size: 109923 bytes md5: f69e720d7cfdc2387edda4970cf587fc No action is required on your part

[cgiapp] [Fwd: CPAN Upload: R/RD/RDICE/CGI-Application-Framework-0.24.tar.gz]

2005-09-24 Thread Richard Dice
Date: Sat, 24 Sep 2005 14:42:30 +0200 From: PAUSE [EMAIL PROTECTED] Reply-To: cpan-testers@perl.org To: Richard Dice [EMAIL PROTECTED] The uploaded file CGI-Application-Framework-0.24.tar.gz has entered CPAN as file: $CPAN/authors/id/R/RD/RDICE/CGI-Application-Framework-0.24.tar.gz size

Re: [cgiapp] CGI::Application performance alternatives

2005-10-02 Thread Richard Dice
Dan, I expect that they're all going to experience the same memory situation. They all operation on basically the same idea. (Though if anyone out there has a different perspective then I'd love to hear it. mod_perl is the only one of them I have extensive experience with.) Don't forget

Re: [cgiapp] CGI::Application performance alternatives

2005-10-03 Thread Richard Dice
Cees said: All in all, you will get the best performance by using backend mod_perl server. However, you can get most of the way there, with lots of flexibility, and little to no configuration with PersistentPerl. In my earlier comments I said that I expected mod_perl to be comperable to the

[cgiapp] Fwd: CPAN Upload: R/RD/RDICE/CGI-Application-Framework-0.25.tar.gz

2005-10-04 Thread Richard Dice
- Forwarded message from PAUSE [EMAIL PROTECTED] - Date: Tue, 4 Oct 2005 14:39:23 +0200 From: PAUSE [EMAIL PROTECTED] Reply-To: cpan-testers@perl.org Subject: CPAN Upload: R/RD/RDICE/CGI-Application-Framework-0.25.tar.gz To: Richard Dice [EMAIL PROTECTED] The uploaded file

[cgiapp] CAF hack-a-thon this Saturday

2005-10-27 Thread Richard Dice
Hi everyone... As many of you would know Michael Graham and I have been putting some effort into the CGI::Application::Framework project. ( http://search.cpan.org/~rdice/CGI-Application-Framework-0.25/lib/CGI/Application/Framework.pm ) Matthew Rice, Michael and I have decided to instigate a CAF

[cgiapp] [Fwd: CPAN Upload: R/RD/RDICE/CGI-Application-Framework-0.26.tar.gz]

2005-10-31 Thread Richard Dice
Original Message Subject: CPAN Upload: R/RD/RDICE/CGI-Application-Framework-0.26.tar.gz Date: Tue, 1 Nov 2005 03:13:47 +0100 From: PAUSE [EMAIL PROTECTED] Reply-To: cpan-testers@perl.org To: Richard Dice [EMAIL PROTECTED] The uploaded file CGI-Application-Framework-0.26.tar.gz has

Re: [cgiapp] Testing

2007-12-12 Thread Richard Dice
I see this. On Dec 12, 2007 10:27 AM, Jesse Erlbaum [EMAIL PROTECTED] wrote: Ping? Jesse Erlbaum The Erlbaum Group, LLC http://erlbaum.net/ 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application in a coding contest

2008-03-10 Thread Richard Dice
Cees, want a trip back to N. America? :-) Cheers, - Richard On Mon, Mar 10, 2008 at 10:46 AM, Jason A. Crome [EMAIL PROTECTED] wrote: I received this last week from Josh McAdams. Sorry for not passing it along sooner, but I was out sick most of last week. I don't have time to do this, but

Re: [cgiapp] Things we talked about at YapcNA 08

2008-07-11 Thread Richard Dice
Hi Leonard, This effort sounds very similar to the CGI::Application::Framework (CAF, occasionally we'd call it caffeine) module that Michael Graham and I released in 2005. We maintained it for a few months afterwards but not since since -- I'm a manager myself these days and barely code, and