Re: [cgiapp] Mailing list shutting down
Update on the future of the list!: *Thomas Krichel has generously offered
to give the list a new home.*
He and I are going to be migrating the list to his server ("*lists.openlib.org
<http://lists.openlib.org>*") in the next few days. Don't be surprised if
you start getting email from this different domain.
Thanks,
Jesse
On Sat, Sep 2, 2017 at 5:07 AM, Michael Hirmke <m...@mike.franken.de> wrote:
> Hi Thomas,
>
> > Jesse Erlbaum writes
> >>
> >> We are finally decommissioning the server which hosts this Mailman
> mailing
> >> list. Since it was started ? *more than 10 years ago!* ? much easier and
> >> better forums for learning how to use CGI-Application have been created.
> >> So, it is my intention to shut down the list, with the server.
>
> > If you give me the members' list, I can continue the list on my server.
>
> I would really appreciate that.
>
> >--
>
> > Cheers,
>
> > Thomas Krichel http://openlib.org/home/krichel
>
> Bye.
> Michael.
> --
> Michael Hirmke
>
> # 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/ ##
> ####
>
>
>
--
*Jesse Erlbaum*
The Erlbaum Group, LLC
817 Broadway, 4th floor
New York, NY 10003
212-684-6161 (office)
917-647-3059 (mobile)
212-684-6226 (fax)
je...@erlbaum.net
# 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/ ##
####
Re: [cgiapp] Mailing list shutting down
Jerry: Even if the list goes away, the framework remains! We still use it on many projects. On Fri, Sep 1, 2017 at 12:36 PM, jerry <je...@tr2.com> wrote: > I would hope that some sort of list continues. I know that there are > newer > and flashier frameworks out there, but cgiapp works well for my > purposes, > and I would not look forward to recoding all my business software. > >Even when I started using it, there was fancier stuff out there. But > for me, > cgiapp had just the right balance of magic ( so I typed less ) and > understandability - so I could adapt it to my specific needs and > troubleshoot it when it didn't work. > > - Jerry Kaidor > > > On 09/01/2017 09:15, Thomas Krichel wrote: > > Jesse Erlbaum writes > >> > >> We are finally decommissioning the server which hosts this Mailman > >> mailing > >> list. Since it was started – *more than 10 years ago!* – much easier > >> and > >> better forums for learning how to use CGI-Application have been > >> created. > >> So, it is my intention to shut down the list, with the server. > > > > If you give me the members' list, I can continue the list on my > > server. > > > > > > -- > > > > Cheers, > > > > Thomas Krichel http://openlib.org/home/krichel > > skype:thomaskrichel > > > > # 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/ ## > > #### > > > > > # 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/ ## > #### > > > -- *Jesse Erlbaum* The Erlbaum Group, LLC 817 Broadway, 4th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) je...@erlbaum.net # 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/ ## ####
[cgiapp] Mailing list shutting down
Hi All! We are finally decommissioning the server which hosts this Mailman mailing list. Since it was started – *more than 10 years ago!* – much easier and better forums for learning how to use CGI-Application have been created. So, it is my intention to shut down the list, with the server. If anyone knows of places where CGI-App discussions are being held these days, please email me or post them to this list! Thanks everybody! Jesse -- *Jesse Erlbaum* The Erlbaum Group, LLC 817 Broadway, 4th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) je...@erlbaum.net # 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/ ## ####
Re: [cgiapp] Re: CGI::Application mailing list is evolving
Hi All -- On Wed, May 6, 2009 at 3:23 PM, Michael Peters mpet...@plusthree.comwrote: Things I want: + Reliable + Easy to use + A more common SCM system (not darcs). SVN is popular and tolerable. Git is nice and fast (and with something like github forking and fixing things becomes more a community thing than just patches in an RT ticket). + Web-based posting (but still keeping the email list) is nice because you don't have to join the group to participate with just a short quick question. I'm already subscribe to too many lists so whenever I can ask a quick question without having to subscribe again it's a win. +1 on all of this! And, also +1 on what John said about maintainers. What I talked to Mark about this morning was that I think the nature of how these projects can be supported is changing. There is a clear multiplicity of features which are useful, beyond just a mailing list. I've used Sourceforge, but I find it dated and shaky. Irrational though it may be, I get a much better feeling about something like Google Code ( http://code.google.com) + Google Groups. I feel like Google is here to stay, and actively gets it regarding software development AND open source. Jesse -- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) je...@erlbaum.net # 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/ ## ####
Re: [cgiapp] Re: CGI::Application mailing list is evolving
On Wed, May 6, 2009 at 3:48 PM, Jesse Erlbaum je...@erlbaum.net wrote: Irrational though it may be, I get a much better feeling about something like Google Code (http://code.google.com) + Google Groups. This being said: http://code.google.com/p/cgi-application/ Just playing around. Anyone want admin access to check this out, let me know. Jesse -- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) je...@erlbaum.net # 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/ ## ####
Re: [cgiapp] CGI::Application mailing list is moving
Please disregard. On Sun, May 3, 2009 at 8:20 AM, Mark Stosberg m...@summersault.com wrote: The CGI::Application mailing list is moving. Please re-subscribe at the new location here: # 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/ ## ####
RE: [cgiapp] Safe way to remember user login?
The way I've accomplished this is by adding something like an md5key column to the users database. When someone checks the remember me button you can generate a key based on something like, their username / password / the current date + some salt (or whatever you like). I do something a bit similar to that. The difference is that the salt is not known to the web browser. The most important part of this idea is that there is a SECRET which is known only to the server. Send the user two cookies: 1. A clear-text version of their username 2. An MD5 hashed version of their user name, salted with the SECRET (Never NEVER give them a cookie with their PASSWORD, or the SECRET.) When the server gets a request from an un-authenticated user who has these cookies, try re-hashing the clear-text username with the SECRET. If it matches the hashed version in the browser, log the user in. As far as relying on the browser to remember UID/PW: Sometimes that's OK, and sometimes that's annoying. There are many sites on which I prefer that I don't have to log in every time I go there. For example, Gmail. Jesse Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) je...@erlbaum.net # 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/ ## ####
RE: [cgiapp] Function CGI::Application Code
Hi Michael -- So I figured that I would share my work with others. All my code has been placed up on websvn and is publicly viewable. Thanks for posting that. It looks like a solid and large body of code, which could be very instructional for CGI-App developers -- old and new alike. Warmest regards, -Jesse- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED] # 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/ ## ####
[cgiapp] [ANNOUNCE] Krang V3.01
Krang v3.01 Release: February 15, 2008 Release Summary This release adds many new, and often requested features. Krang now supports multiple windows, permitting users to edit more than one story at a time. A syntax-highlighting text editor has been added for editing templates and text-based media (CSS, Javascript, HTML, XML, etc.). Numerous small bugs have been fixed, and performance enhanced. Significant improvements have been made to Krang's UTF-8 (Unicode) support. Major changes in this release include: * Multiple Krang window support. Edit more than one story at once! * Syntax highlighting for template editing. * Online editing of text media (e.g.: CSS, Javascript, HTML, text, XML, etc.) * Previewing a story now respects edited form fields -- no more endless save stay + preview * When editing media, made Save and Save Stay buttons automatically publish to preview. * Added ability to replace one story with another in one step. * Improved UTF-8 support. * Fixed numerous bugs and improved overall performance. About Krang Krang is an open source web publishing/content management system, particularly well suited for high volume magazine-style web sites. Originally developed in 2003 by Primedia, Krang is currently used by hundreds of well-known web sites including New York Magazine, Motor Trend, Soap Opera Digest, In-Fisherman, Guns Ammo, Florida Sportsman, Game Fish, Equisearch.com, Power Motor Yacht, and many more. Krang provides a powerful and easy to use story and media editing environment for website editors, as well as a complete template development environment for web designers. On the back-end, Perl programmers can customize Krang to control the data entered in the story editor and add code to drive the templates to build output. Krang can be enhanced with add-ons containing new skins and other new features. Krang easily handles large data sets and can manage multiple websites in a single installation. Krang Links Krang CMS web site: http://www.krangcms.com Full change log: http://www.krangcms.com/docs/changelog.html#3_01__february_1__2008 Download from SourceForge: http://sourceforge.net/project/showfiles.php?group_id=103045 Mailing lists: http://lists.sourceforge.net/mailman/listinfo/krang-devel http://lists.sourceforge.net/mailman/listinfo/krang-general Bug Tracker: http://bugzilla.krangcms.com Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 http://erlbaum.net [EMAIL PROTECTED] # 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/ ## ####
RE: Re: [cgiapp] How to send pdf file?
Hi Petr --
MIME headers are correct, but I still don't know how to send binary
output through CGI::Application.
On classic way it is easy:
open(FILE, test.pdf);
@fileholder = FILE;
close (FILE);
print Content-Type: application/pdf\n;
print Content-Disposition: attachment;filename=test.pdf\n\n;
print @fileholder;
How to do it through CGI::Application?
It's basically the same w/ CGI::Application, with two exceptions:
1. You don't return the headers. You set them.
2. You don't print -- you return your data.
sub send_pdf {
my $self = shift;
$self-header_props( -type = application/pdf,
-Content-Disposition=attachment;filename=test.pdf
);
open(FILE, test.pdf);
@fileholder = FILE;
close (FILE);
return join(, @fileholder);
}
TTYL,
-Jesse-
Jesse Erlbaum
The Erlbaum Group, LLC
817 Broadway, 10th floor
New York, NY 10003
212-684-6161 (office)
917-647-3059 (mobile)
212-684-6226 (fax)
[EMAIL PROTECTED]
# 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/ ##
####
[cgiapp] Testing
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] blocked::mailto:[EMAIL PROTECTED] # 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/ ## ####
[cgiapp] testing
Just a test. Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED] blocked::mailto:[EMAIL PROTECTED] # 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/ ## ####
[cgiapp] List back up
Hi All -- We suffered a bit of a list malfunction for the past few days. Everything is back up now. FYI, the cause of the problem was that RedHat's up2date fixed the ownership on the mailman home directory. The result was that Qmail (the MTA here) viewed this as a security problem. I'm not yet clear on whether email sent was lost. (If not, it'll probably start to flow in.) Sorry for the snafu! -Jesse- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED] blocked::mailto:[EMAIL PROTECTED] # 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/ ## ####
[cgiapp] [ANNOUNCE] Krang V3.00
Krang v3.00 Release: November 20, 2007 Release Summary Krang version 3.00 (Kv3) is a complete rewrite of the CMS user interface. The new UI is fully AJAX-enabled and redesigned for greatly enhanced ease of use. In addition, dozens of functional changes have been made to the CMS to make common tasks easier, and to add many new capabilities. The result is a much easier, faster, and more robust user experience. Major changes in this release include: * New AJAX interface and Javascript re-write. * Completely new skin. * Save button in story editor now truly saves to disk even when editing a sub-element. * Automatic slug-generation based on title and story type. * Any story type may now be a category index (aka, cover). About Krang Krang is an open source web publishing/content management system, particularly well suited for high volume magazine-style web sites. Originally developed in 2003 by Primedia, Krang is currently used by hundreds of well-known web sites including New York Magazine, Motor Trend, Soap Opera Digest, In-Fisherman, Guns Ammo, Florida Sportsman, Game Fish, Equisearch.com, Power Motor Yacht, and many more. Krang provides a powerful and easy to use story and media editing environment for website editors, as well as a complete template development environment for web designers. On the back-end, Perl programmers can customize Krang to control the data entered in the story editor and add code to drive the templates to build output. Krang can be enhanced with add-ons containing new skins and other new features. Krang easily handles large data sets and can manage multiple websites in a single installation. Krang Links Krang CMS web site: http://www.krangcms.com Full change log: http://www.krangcms.com/docs/changelog.html#3_00__november_20th__2007 Download from SourceForge: http://sourceforge.net/project/showfiles.php?group_id=103045 Mailing lists: http://lists.sourceforge.net/mailman/listinfo/krang-devel http://lists.sourceforge.net/mailman/listinfo/krang-general Bug Tracker: http://bugzilla.krangcms.com Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED] # 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/ ## ####
RE: [cgiapp] posts blackholed?
I sent a number of posts to the list last night. Only one went through. This morning, I tried the missing ones again. Nothing went through. What's up? The messages are coming through now. Probably a list server configuration issue. -Jesse- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED] # 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/ ## ####
RE: [cgiapp] strategies for decoupling HTML::Template
I am not a big fan of HTML::Template. It just doesn't float my boat. It bugs me a little bit that it's a prereq of CGI::Application, especially when it isn't, then, really needed. I am a big fan of HTML::Template, which is why I put in there in the first place. In spite of the fact that I have a strong preference, I made it easy (nay, trivial) to swap in your own templating system. Your request has been heard, and respectfully declined. (You're not nearly the first to make it.) You're going to have to hold your nose and let CPAN install HTML::Template even though you don't use it because it's part of the core, and it's needed for many existing applications (as you've noticed). -Jesse- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED] # 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/ ## ####
[cgiapp] New mailing list server
Hi All - As David indicated, we have switch the CGI::Application mailing list over to Mailman. If anyone has any difficulty with the new server, please email me directly. Warmest regards, -Jesse- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) 212-684-6226 (fax) [EMAIL PROTECTED] blocked::mailto:[EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappamp;amp;amp;r=1amp;amp;amp;w=2 To unsubscribe, or change your message delivery options, visit: http://www.erlbaum.net/mailman/listinfo/cgiapp
[cgiapp] Plucene or Xapian?
Hi All -- Has anyone here built a Perl/CGI based search using Plucene or Xapian? What are your experiences? Has anyone here used another modern system besides these two? Thanks, -Jesse- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) [EMAIL PROTECTED]
RE: [cgiapp] Plucene or Xapian?
Hi Peter -- As one of the Swish-e developers, I can second Michael's endorsement. ;) I've used switch-e many times over the years. Do you think it is lacking in any way compared to Xapian or Plucene? What about compared to commercial systems such as Verity or Autonomy? I've felt that Switch-e was a bit long in the tooth owing to its legacy. Do you disagree? If you were not deeply involved in the Switch-e project, would you choose it over Xapian or Plucene (or any other system)? That said, I would suggest Xapian over Plucene, hands down. Why do you say? Any particular gripes? And I would also check out KinoSearch, which is (along with Xapian) going to be one of the optional backend IR libraries for the next version of Swish-e. I've heard of KinoSearch before, but I've not tried it out. It seemed that Plucene and Xapian had more established Perl interfaces, but I could be wrong. -Jesse- Jesse Erlbaum The Erlbaum Group, LLC 817 Broadway, 10th floor New York, NY 10003 212-684-6161 (office) 917-647-3059 (mobile) [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Re: CGI::App and HTML::Template subclasses
Hi Viacheslav --
Let's don't write plugins for every H:T-style module! Setting
something
like:
$self -{__CURRENT_TMPL_MODULE} = 'HTML::Template::Compiled';
in your App will do all the job .
Not necessary. As people have said, there are numerous CGI-App plug-ins
which already do this. Even if you didn't want to use a plug-in you
could override load_tmpl() in your CGI-App subclass.
package My::CgiApp;
use base 'CGI::Application';
sub load_tmpl {
my $self = shift;
require 'HTML::Template::Compiled';
# ... Etc.
}
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] RFC: Thumbnail Image Server
Hi Ron All -- My thoughts about the name (in loose order of preference): WWW::ImageServer My preference too, but then I did not think too hard... Apache::ImageServer Apache? Will it be crippleware, ie refuse to run on other web servers (not that there are that many choices)? CGI::Application::ImageServer Understandable choice, but my policy these days is to use names which describe what a module does, rather than describe what components were used to provide the module's services. How about: HTTP::ImageAbuser Too obscure? Too cute? As a few others pointed out, most of the WWW:: space is clients, so HTTP:: might be a better place. Also, this will work on non-Apache servers (although, I'd like to make it work particularly well in Apache). -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] RFC: Thumbnail Image Server
Hi All -- I'm working on a CGI-App based module for CPAN, and I'm looking for feedback in three areas: 1. Is there anything similar? 2. Is this useful / what features would make it more useful to you? 3. What should it be called? This application will dynamically create and cache image thumbnails at request time, among other things. The ultimate goal is a Perl-based implementation approaching Amazon's image server: http://aaugh.com/imageabuse.html Essentially, given a particular request's parameters and a source directory containing high resolution images, images will be manipulated and returned to the user. This will obviate the need for laborious graphic production and re-production every time the high-res versions change. For example: http://foo.com/images/bigimage.jpg -- Returns high-res image http://foo.com/images/640/480/bigimage.jpg -- Returns 640x480 version of same image Exact URL structure TBD. When the request comes in the high-res version and the cached thumbnail will be stat'd. If the thumbnail does not exist or is older than the high-res version, a thumbnail will be re-created. First goal is thumbnails, but ultimately this should be extensible to all variety of auto-manipulation. My thoughts about the name (in loose order of preference): WWW::ImageServer Apache::ImageServer CGI::Application::ImageServer Any other suggestions? (I'm open to changing ImageServer to something else.) Thanks, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Seeking Senior Perl Coder (Contract)
Hi Guys -- The Erlbaum Group is looking for a very experienced, organized Perl coder to join our little crew. TEG specializes in implementing enterprise-class content management systems using the Krang system, as well as custom web application development. Besides the money and the excitement, you will also be working along side a great team of very talented people, on a project of significance, for well-known clients. If all goes well, an opportunity exists for long term contract work or a staff position. This is an 80-100% on-site assignment. Please do not apply if you're not ready to work in New York, NY. Rate: Starting at $60/hr Required skills: * Must be highly organized, thoughtful, self-starter * Excellent written and spoken communication skills * Experienced to Expert OO/Perl programmer * Experienced to Expert in SQL/MySQL * Experienced to Expert UNIX developer * Expert web development skills Desired skills: * CVS/SVN revision control * CGI::Application, HTML::Template * Krang CMS (http://krang.sf.net/) * Experience on large projects * Experience with small teams * Experience in magazine publishing industry * CPAN authors welcomed! Please email me (off list!) with your resume, availability, and rate. Be prepared to show code samples. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Rapid Website Development with CGI::Application
Congrats to Mark on his article!: Rapid Website Development with CGI::Application by Mark Stosberg October 19, 2006 http://www.perl.com/pub/a/2006/10/19/cgi_application.html -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Site layout best practices question
Hi Ed --
Now I'm starting to get ready for deployment and have turned
on Taint
mode with the -T option of the instance scripts and need to untaint
the the environment variables. Is there a best practice for this?
I generally don't use taint because I've found it to be a huge pain in
the ass, with dubious security value. (It warns on many things which
don't matter, and encourages the programmer to write bad regular
expressions to hush up the warnings. If I wanted a language which
forces me to jump through useless hoops, I'd use Java!)
That said, to untaint PERL5LIB I stick the following at the top of all
my instance scripts:
#!/usr/bin/perl -wT
BEGIN {
$perl5lib = $ENV{PERL5LIB};
$perl5lib =~ /^(.*)$/;
$perl5lib = $1;
}
use lib $perl5lib;
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] How to split runmodes into different modules
Hi Michael --
No, this is not the reason, why I want to split my application but
still, I am not convinced that authorization belongs in Apache. Say I
have an application with a company and branches. Now I want
that a user
is only allowed to run the runmodes with data of the brach the user
belongs to.
This info is within the application and Apache doesn't know anything
about it -- at least if I don't want to duplicate my branch
layout in a
htgroups file or similar.
Or if this case is still simple enough that with some tricks
Apache can
use the info in the database, what about special cases where
a user is
granted rights just for part of the info, say anything,
except sallary?
The 'knowledge' about the different roles of users is
inherently within
the application and I cannot see how Apache can do really flexible
access restriction without being part of the application.
Good questions!
Let me start by separating Authentication from Authorization. The
former is the means of identifying the user who is logged in. The
latter is determining if that user is allowed to do a particular thing.
That being said, I think we can all agree that the means to determine
the identify of the user doesn't change at the application layer, and
may be entirely implemented in Apache. That leaves us with
Authorization. Authorization happens in many ways. There is general
authority, and there is the sort of fine-grained authority you refer to
in your message.
General authority might refer to whether a user is an anonymous public
user, a logged-in user, or an administrator. Tao Apache might suggest
that any request to the /admin/ directory require that the user is an
administrator, otherwise they are redirected to another page. Perhaps
only logged-in users (or administrators) may access the /membersonly/
directory.
This is the type of security for which Apache was designed. Apache's
whole security model is based on paths. Using the Location directives
(or .htaccess files) and require group directives you could easily
configure this type of general security. If you judiciously make use of
CGI-App instance scripts, as I described in my last message, you can
combine that with Apache's security philosophy to achieve probably 80%
of what you need.
That leaves the last 20% of the picture: Fine-grained authorization.
You describe situations where a user might not see a particular column,
or not be allowed to change a particular field. Once you get to the
point of contending with fine-grained security, you generally have to
add this code to your application layer.
Fortunately, you already know who the user is, and know that they are
allowed into the application. You only need to make very specific
tactical decisions. Your code can refer to the REMOTE_USER environment
variable with confidence that it is populated with a valid user. If you
have programmed your Apache Authorization module to do so, the user's
detailed authority settings may already be in the environment,
permitting you to know what fine-grained authority the user has without
the need to query a database again. All you have to do is:
show_delete_button() if ($ENV{USER_MAY_DELETE});
If you take the time, you could even centralize this logic in Perl
modules and in your HTML template layer. In Krang, for example, we use
a strict Model-View-Controller architecture. In the Model modules we
query the user's permissions to determine if they are permitted to edit
the particular object (e.g., a Story object in a particular category)
they are trying to edit. If the user attempts to save() or delete() an
object they are not permitted to edit, we throw an Exception::Class back
to the CGI-App (Controller), which is then caught and conveyed into
action: an alert to the user, entries in the security logs, etc.
Designing a system like this takes time, but it pays for itself ten-fold
in extensibility, reliability, and ease of future development.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] How to split runmodes into different modules
Hi Richard -- Sounds interesting. Any chance you could post - or point to - an example of how to get started with that sort of thing? I got started by reading the source of Apache::AuthDBI (part of the Apache::DBI package). In Apache::AuthDBI you will see the essential ingredients of a custom Apache Auth* module. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] How to split runmodes into different modules
Hi Michael Michael -- If you want a working example, check out Krang (http://krang.sourceforge.net). It's one really big CGI::Application. That's not true. Krang is not one big cgi-app. Krang is actually composed of multiple, separate CGI::Application modules, each launched via their own instance script: htdocs/media.pl htdocs/history.pl htdocs/about.pl htdocs/schedule.pl htdocs/my_alerts.pl htdocs/category.pl htdocs/desk.pl htdocs/story.pl htdocs/media_bulk_upload.pl htdocs/workspace.pl htdocs/bug.pl htdocs/debug.pl htdocs/site.pl htdocs/status.pl htdocs/publisher.pl htdocs/group.pl htdocs/env.pl htdocs/user.pl htdocs/help.pl htdocs/my_pref.pl htdocs/desk_admin.pl htdocs/contributor.pl htdocs/login.pl htdocs/template.pl htdocs/list_group.pl These separate applications are tied together (in some cases, very tightly) to produce the effect of one big application, which is the goal for any project, I imagine. This is done through links, sessions, centralized security, and clear-headed thinking. I do strongly agree that Krang is a good example of the use of CGI-Application. (And I'm not just saying that because I helped design it!) We spent time to thoughtfully consider what run modes belong in which applications, and how they should function together. One example of what is possible with this architecture is the add_message facility. (This elegant system was designed by Sam Tregar.) By cleverly using sessions and a custom CGI-Application parent class, the developer can easily send a message to another page, even if that page is in another application. For example, if you save a story you are redirected back to your workspace with a message at the top of the screen, Story XYZ saved. I'm obviously a proponent of the organizational scheme Krang uses. As far as multiple instance scripts: The idea is that each script (really, each URL -- that is the main purpose of an instance script) represents an entry point into a task. You could type in the URL of the instance script and begin a task. It's a point of looser coupling. IOW, the run modes *within* one CGI-App are more closely related to each other than to a separate CGI-App. This idea is core to the philosophy of CGI-Application. If you don't believe in this philosophy, I think you might find that a server page system will work better for you. One other note, on which I have been harping for years: If you are about to tell me that you can't have a separate instance script for each application because your login system would have to be duplicated in each application, then you're doing things wrong. Authentication and authorization belongs in Apache -- not in your CGI-App module. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] catch-all in CGI::Application::Dispatch
Like having one more name value pair passed to the dispatch()
method like:
no_match = { '/myapp/notfound/'},
which will be used if nothing else matches.
There is a facility like this built directly into CGI::Application:
THE RUN MODE OF LAST RESORT: AUTOLOAD
If CGI::Application is asked to go to a run mode which doesn't exist it
will usually croak() with errors. If this is not your desired behavior,
it is possible to catch this exception by implementing a run mode with
the reserved name AUTOLOAD:
$self-run_modes(
AUTOLOAD = \catch_my_exception
);
Warmest regards,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] FORM MAIL error
Hi Ignacio --
This mailing list is *NOT* for general Perl CGI questions. For general
questions, go to the USENET groups comp.lang.perl.misc or
comp.infosystems.www.authoring.cgi.
This mailing list is for users of the CPAN Perl module CGI::Application:
http://search.cpan.org/dist/CGI-Application/
You can find out more about this module at:
http://www.perl.com/pub/a/2001/06/05/cgi.html
-Jesse-
-Original Message-
From: Ignacio Nieto [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 22, 2006 10:57 AM
To: cgiapp@lists.erlbaum.net
Subject: [cgiapp] FORM MAIL error
Dear Mark and all
I test the CGI with these form had these form and
doesnt work. Could somebody help me' Thanks Ignacio
html
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01
Transitional//EN
http://www.w3.org/TR/1999/REC-html401-19991224;
head
titleundefefined/title
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1
style type=text/css
!--
#first {
font-family:verdana;
font-size:12px;
color:#fff;
background:#000;
}
//--
/style
script type=text/javascript
!--
var parrafo1 = new Array(a1, a2);
var parrafo2 = new Array(b1, b2);
var parrafo3 = new Array(c1, c2);
function RandomTitle(nameform) {
a = Math.floor(Math.random() * parrafo1.length);
b = Math.floor(Math.random() * parrafo2.length);
c = Math.floor(Math.random() * parrafo3.length);
nameform.first.value=parrafo1[a] + parrafo2[b] +
parrafo3[c];
document.forms[0].submit();
}
//--
/script
/head
body
form action=cgi-bin/forma.cgi method=post
tabletr
td height=31 width=278
input type=submit name=generate value=abrir
onclick=RandomTitle(this.form)
/td
/trtr
td
textarea id=first name=first cols=30 rows=4
/textarea
/td
/tr/table
/form
/html
#!/usr/bin/perl
# Enter the location of sendmail.
$mailprogram = /usr/sbin/sendmail -t -i
[EMAIL PROTECTED];
# Enter your e-mail address. Be sure to put a \
in
front of the @.
# ([EMAIL PROTECTED] becomes [EMAIL PROTECTED])
$youremail = [EMAIL PROTECTED];
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(//, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~
s/%([a-fA-F0-9][a-fA-F0-9])/pack(C, hex($1))/eg;
$FORM{$name} = $value;
}
open (MAIL,|$mailprogram);
print MAIL To: $youremail\n;
print MAIL $FORM{'linea1'}\n;
print MAIL $FORM{'linea2'}\n;
print MAIL $FORM{'linea3'}\n;
print MAIL $FORM{'linea4'}\n;
print MAIL $FORM{'linea5'}\n;
print MAIL $FORM{'linea6'}\n;
On 2006-01-13, Ignacio Nieto
[EMAIL PROTECTED] wrote:
Hello
I had a the following script. Is there any
posibility
to send mail to another emails account that belong
to
other domains?
thank you
Ignacio
#!/usr/bin/perl
# Enter the location of sendmail.
$mailprogram = /usr/sbin/sendmail -t -i
[EMAIL PROTECTED];
# Enter your e-mail address. Be sure to put a \
in
front of the @.
# ([EMAIL PROTECTED] becomes [EMAIL PROTECTED])
$youremail = [EMAIL PROTECTED];
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(//, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~
s/%([a-fA-F0-9][a-fA-F0-9])/pack(C, hex($1))/eg;
$FORM{$name} = $value;
}
open (MAIL,|$mailprogram);
print MAIL To: $youremail\n;
print MAIL $FORM{'linea1'}\n;
print MAIL $FORM{'linea2'}\n;
print MAIL $FORM{'linea3'}\n;
print MAIL $FORM{'linea4'}\n;
print MAIL $FORM{'linea5'}\n;
print MAIL $FORM{'linea6'}\n;
close MAIL;
Certainly. You are allowing the query string to
become part of your
header. So simply:
script.cgi?linea1=Bcc:[EMAIL PROTECTED],[EMAIL PROTECTED]
Even for simple web to emails, I might still use
CGI.pm for the query
processing, MIME::Lite for the e-mail building, and
HTML::Template
to seperate the design from the program.
(HTML::Template works fine for
e-mail templates despite the name.
Mark
-
Web Archive:
http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CAP::AutoRunmode::FileDelegate
Hi Richard -- It seems a bit quiet here at the moment. I could do with some help with CAP::AutoRunmode::FileDelegate - basically I cannot get it to work using the documentation as provided. Depending on how I configure the system I get one of the following: I can't help you with that error, but out of curiosity: Why did you choose ::FileDelegate? Perhaps a more pointed version of the same question: Why did you choose to use ::FileDeletegate instead of a more fully thought-out server page system like Mason? -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ideas for limiting delegates in the AutoRunmode plugin
My concept for the module was that a delegate is a class that only contains runmodes. So the way to mark methods as run-modes is to group them in a package and use that package as a delegate. Anything that is not a runmode must not be in that package. Isn't this a bit of a Rube Goldberg machine? What is the shortcoming of just declaring your run modes with the run_modes() method? $self-run_modes([qw( list of method names which are run modes )]); -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ideas for limiting delegates in the AutoRunmode plugin
Without a mechanism like this, it's awful tempting just to declare everything a run mode... Which you don't want to do. This would permit a malicious user to call any internal method. -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Everything is a plugin
Hi Cees --
my $rm_param = $self-mode_param() || croak(No rm_param()
specified);
my $rm;
# Support call-back instead of CGI mode param
if (ref($rm_param) eq 'CODE') {
# Get run mode from subref
$rm = $rm_param-($self);
}
# support setting run mode from PATH_INFO
elsif (ref($rm_param) eq 'HASH') {
$rm = $rm_param-{run_mode};
}
# Get run mode from CGI param
else {
$rm = $q-param($rm_param);
}
We could rewrite that like this:
my $rm = $self-get_the runmode_for_the_current_request();
How about just using the code ref feature which already exists?:
$self-mode_param(\get_the runmode_for_the_current_request);
Refactoring is a fine thing, but I'm concerned about creating Code-TOFU:
A system which is so generalized that it doesn't actually add any value
over just writing what you want from the start. What does it mean is
every line of code is optional? Not much.
Rob: Submit a patch. I'd like to see what you're proposing, but
talking in abstracts isn't helping your case. I'm not saying we're
going to accept the patch, but if you have an idea I think code is going
to make more sense than prose.
I am a use-case oriented guy. Tell me a real thing (not a potential,
imagined thing -- some actual thing you need to do today) you're trying
to do which you can't do, and we'll talk about it.
And, FYI, I always thought the Apache guys over did it with the request
phases. Considering most people don't understand the difference between
authentication and authorization and access, or what the heck a
fixup handler is for, citing them as an example isn't doing it for me.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Everything is a plugin
Instead of trying to guess all the different plugin points a developer
could want, we could implement a syntax by which the developer could
make their own plugin calls. We could call it Perl!
Lol... I was about to write the same thing.
Kidding aside, my favorite thing about CGI::Application is its
simplicity. It's a simple module which gets its job done in a very
small amount of code. Jesse used to say that CGI::App was more of a
philosophy than a technology, and that suited me just fine. The pace
of recent development makes me wonder how long that will remain true,
if it still is.
At it's essence, the CGI::Application module must be able to do things
simply:
use base 'CGI::Application';
sub setup {...}
sub my_runmode {...}
If anyone wants to create a module which requires that you specify
plugins, or forces you to do anything more than declare and implement
run mode methods, then go and write your own framework. (May I
recommend you call it CGI::Application::Very::Simple::And::Lite? Heh..)
Let's not try to make CGI::App into a plugin system for every
web-development task. The world has enough of those already. Or, put
another way, if what you really want is Catalyst then you know where
to find it.
Thank you!
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ANN: Plugin for HTML::Template::Compiled
- die_on_bad_params has been removed (yay!) Does this mean that you can pass any bad param into the template and it doesn't die? For me, this is the template equivalent of use strict. -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] A new project name for CGI::Application
Hi David -- I think we're stuck with CGI::Application: I don't think the module name should change, but there is a larger architecture at work here, and I am all for naming it and promoting it. CGI-App (the module) is only one part of that architecture -- maybe a central part, but only one part. Let me say one thing about my own experience talking to people about the module: I'm getting a little tired of explaining to people ...don't let the 'CGI' in 'CGI-App' fool you -- it is not necessarily CGI-based. It does seem like some antiquated compatibility layer, if you only hear the name. I have it in mind to create a new CPAN module -- a Bundle which loads CGI-App and all the other popular modules. This bundle would also contain some infrastructure which implements popular best practices -- for instance, harness scripts to build up project scaffolding at the start. BTW, I'm involved in a project called Matchstick (a spin off of the Krang CMS project) which covers some of these goals. It would make much sense to integrate that into this. http://sourceforge.net/projects/matchstick/ That being said, in an effort to come up with a better name, I propose we assemble a master list of names and then vote them off the island until we have a winner. Anyone want to assemble a master list to start? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Voting method
I'm not too picky about the particulars. Using a simple in order of preference, drop loser and redestribute until one choice has 50% is fine, but so is full Condorcet(sp) or anything else. Instant run-off election. I like it. Now, all we have to do is write a CGI-Application based voting application. ;-) -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Best free DB for a web-based Perl app response results...
MySQL -- no graduation necessary: Just good application architecture. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Best free DB for a web-based Perl app response results...
Hey Fred -- I would just like to note that speed and reliability are largely dependent on the transaction profile of your application. If your application is read heavy, MySQL is a sound choice. However if your application consists mostly of database writes, PostgreSQL's MVCC [1] architecture and row-level locking capabilities will generally provide superior performance and reliability to MySQL. I question your assertion that PgSQL's row-level locking is faster than MySQL's row-level locking. I'd like to see actual benchmarks before saying that one particular approch is faster than another. -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Best free DB for a web-based Perl app response results...
Hey Jeff -- Regarding teh rest of your email, I have got to agree with you, most web apps use way more resources than they could possibly need, but you know what ? As a counter to your argument if you needed Oracle you'd just use Oracle VS PgSQL, in my life, if i only needed MySQL, i'd use SQL Lite. I really don't think your SQL Lite analogy is a valid one. Oracle, PgSQL and MySQL are hugely popular. SQL Lite is a skunk works with no proven track record. Quick Google hits check: 2,250,000 for Oracle +rdbms 756,000 for MySQL +rdbms 384,000 for PostgreSQL +rdbms 207 for SQL Lite +rdbms A bit of a straw man, wouldn't you say? -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Best free DB for a web-based Perl app response results...
Hi Cees -- Agreed. You don't often need those things for a simple web app. In fact DBM files are sufficient for lots of web apps (and probably faster too). And there is always sqlite, but it won't scale very well. I disagree with you that DBM files are sufficient. Even the simplest web database needs: * A standard query interface (e.g., SQL) * Concurrency protection / Multi-user capability Given the simplicity of setting up a MySQL database (and it's easy availability -- even in shared hosting environments), I am constantly annoyed when I come across an app which insists on using DBMs. Agreed on cursors, but I disagree about transactions. You describe long lived transactions here, and those aren't very useful on the web. But when updating multiple tables at the same time, transactions are incredibly handy. Rollbacks are very important for data integrity, something that has never been a strength of MySQL. Of course with InnoDB tables you can do transactions in MySQL, so that is not really a differentiator between the two. I hear what you're saying, and there is some truth to it. Assuming you're using MyISAM (non-transactional) tables, it would require table locking to accomplish something similar to transactions, and in that case you still wouldn't get rollbacks. However(!), a lot of this is solved by application architecture. Take the need for a rollback. I am of the school of thought that the application should measure twice, cut once -- IOW, don't go and try to do something you shouldn't do. That is the typical case where you'd need a rollback. For example, if you tried to add a customer who already existed. If you look at my code in that situation you would see me first check, THEN insert. As opposed to the rollback model where (I suppose) you'd insert, wait for an error, and then rollback. (Examples over-simplified and contrived for obvious reasons.) There are tonnes of other annoyances with MySQL but I'll only list a I disagree. I believe there are only tons. ;-) couple that 'really' annoy me: - the first timestamp field in any table is always updated on every UPDATE - -00-00 is a valid date in MySQL - 2005-02-30 is a valid date in MySQL - insert NULL into a NOT NULL column and MySQL will give it a default value - overflowing data is truncated instead of returning an error Some of these I agree with you, others I don't. Perhaps it is because I wasn't born into the ANSI SQL world, but I do believe it is the job of the application layer to check data before it blindly goes and inserts it into the database. MySQL is very Perl-ish in these ways. It is thoroughly DWIM. MySQL also adheres to the Perl idea of let the simple things be simple, and the difficult things be possible. (With PgSQL, it's in for a dime, in for a dollar -- even simple things are relatively complicated.) Being a Perl fan, you can see why I'm also a MySQL fan. Let's not forget that the P in Perl stands for Practical. PgSQL was created as an academic exercise: Can we write our own Oracle? If I wanted to be academically correct, I'd be programming in Java. I don't, and I'm not. Now you are getting silly Jesse. Ad Hominem attacks? Not at all! I'm not impugning academia. I'm commenting on the fact that my personal programming preference is practical -- not ivory-tower perfect (academically correct, as in politically correct). Java is a language which tries to be correct (similar in that way to PgSQL), and I think it's safe to say that most people on this list who have used both Java and Perl can rattle off reasons why they prefer the latter. after years of stating that 'all those academic features are unecesary', they have gone and implemented them anyway in 5.0. Over the years I have described these two projects as follows: * MySQL: Bottom-Up. Always be fast and reliable, and move towards full features. * PgSQL: Top-Down. Always be full featured, and move towards speed and reliability. It has always been the plan for MySQL to build out all the features. It was only a matter of priority. The only question is who gets there first, best. But, of course you can run huge database on MySQL. It takes a bit of work, but it can be done. However, that doesn't mean you can't also do the same thing with PostgreSQL. But who has? What is the equivalent of Sabre (or Google, or Yahoo) for PgSQL? At any rate, both databases are pretty close on many counts. What you get down to is a matter of personal preference. I think that's pretty much what everybody is saying at this point. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL
[cgiapp] JOB: Mod_perl application developer
Hi All -- The Erlbaum Group is looking for an experienced, organized Perl coder to join our little crew. TEG specializes in implementing custom web/database applications and content management systems. Besides the money and the excitement, you will also be working along side a great team of very talented people, on a project of significance, for a very well-known and important client. If all goes well, an opportunity exists for long term contract work or a staff position. Company: The Erlbaum Group, LLC Location: 826 Broadway (near Union Square), New York, NY Terms: Contract Length: 3-5 months Hourly Rate: $65 per hour Required skills: * Must be highly organized, self-starter * Excellent written and spoken communication skills * Experienced to Expert OO/Perl programmer * Experienced to Expert in SQL/MySQL * Experienced to Expert UNIX developer * Expert web development skills Desired Skills: * CVS revision control * CGI::Application, HTML::Template * Krang CMS (http://krang.sf.net/) * Experience on large projects * Experience with small teams * Experience in magazine publishing industry * CPAN authors welcomed! This is an 50-100% on-site assignment. Please do not apply if you're not ready to work in New York , NY. Please send cover letter, resume, code sample, availability, and hourly rate to [EMAIL PROTECTED] (Did we mention we're looking for someone with attention to detail?) -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Ajax?
Hey Tim --
Say, has anyone got a minimal example of embedding AJAX into
a CGI::APP,
preferably using some library to abstract the Javascript (CGI::Ajax or
SAJAX or something else) ?
I'm sure a few other people will email you examples of AJAX
implementations. I just wanted to make one point: CGI-App's run
modes construct is perfect for AJAX applications.
AJAX is, essentially, a single web page which has functions within it
which require server side integration. Put most simply: Web functions
*WITHOUT* their own web page. This is the exact opposite of a server
page system (Mason, EmbPerl, ASP, JSP, PHP, etcetera). This is,
however, exactly the purpose of CGI::Application. Functions without
pages.
Consider a function to do auto-completion of a form field in-page. One
example might be product IDs -- the user types in the first couple
letters, and possible completions appear as drop-down options. This
would easily be implemented as a run-mode:
sub propose_products {
my $self = shift;
my $q = $self-query();
my $prefix = $q-param('product_name');
my @candidates = $self-get_products_starting($prefix);
return join(\n, @candidates);
}
Your Javascript would make an HTTP request on timeout (for example, when
the user stops typing for a couple seconds). That request would be
internal, and would get back a line-delimited list of options, which
would then be displayed via DHTML.
Through this structure, it is easy to see how CGI::Application's
inherent philosophy is eminently compatibly with AJAX. (In fact, it's
almost like it was made for it!)
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Ajax?
I completely agree. I wonder how hard this AJAX transition will be for frameworks that rely on page-style sites. I can see it now: A separate file for every function, and they will love it. (To be fair, in Java that will be three separate files for every function, plus a big honkin' EJB library and an XML configuration file. And they will love it, too.) -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] JOB: Perl Samurai Sought for Serious CMS Project
The Erlbaum Group is looking for a very experienced, organized Perl coder to join our little crew. TEG specializes in implementing enterprise-class content management systems using the Krang system. We are currently engaged in a major effort for a world-renown publishing company, and require a new team member to help out. Besides the money and the excitement, you will also be working along side a great team of very talented people, on a project of significance, for a very well-known and important client. If all goes well, an opportunity exists for long term contract work or a staff position. Required skills: * Must be highly organized, self-starter * Excellent written and spoken communication skills * Experienced to Expert OO/Perl programmer * Experienced to Expert in SQL/MySQL * Experienced to Expert UNIX developer * Expert web development skills Desired Skills: * CVS revision control * CGI::Application, HTML::Template * Krang CMS (http://krang.sf.net/) * Experience on large projects * Experience with small teams * Experience in magazine publishing industry * CPAN authors welcomed! This is an 80-100% on-site assignment. Please do not apply if you're not ready to work in New York , NY. Please send cover letter, resume, code sample, availability, and hourly rate to [EMAIL PROTECTED] (Did we mention we're looking for someone with attention to detail?) Location: New York, NY Company: The Erlbaum Group, LLC Terms: Contract Length: 3 months -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CRUD/BREAD style template question
Hi Brett -- I've found myself spending extra cycles making sure the Read templates are updated whenever the Update templates are. Laziness demands that I consider how to automate that. Now I could write a simple wrapper that generates the HTML for both, but that requires that all of my templates look the same, which is very much not the case here, various apps are highly worked over by the designer. What you've just described in the second paragraph is a compelling argument *AGAINST* automating your page creation, as described in the first. Focus on the purpose of templates: * To allow the presentation to be separated from the code. * To allow non-programmers to make changes to the presentation. It is not at all surprising that there are different templates to represent the same data. That is a benefit -- not a liability. By trying to overload one template to perform both functions you are taking power out of the hands of the template designer by making gross assumptions about how the data will be visually presented. Now, if your project is small enough that the person who is writing the code is the same as the person who is slinging the HTML, then by all means, assume away. If you're using TT, then chances are your HTML person also has Perl chops. If you don't mind putting presentation dependencies into your Perl code, then automate away. (It's anathema to me, but maybe it works for your environment.) Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::App Generator
Hey All -- BTW, if someone wants to take over the CGI::Application::Generator module, that's OK with me. -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] The future of the CGI::App web presence
Hey Mark -- Do others share my interest in moving to another wiki to upgrade the experience? Among those subset of you, are their volunteers for hosting and managing it? As a group, our choice will be heavily influenced by the options that would-be volunteer administrators present as ones they are willing to admin. I'd like to host it, if nobody is opposed. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ANNOUNCE: CGI::Application::Search
Hi Michael -- It's a C::A based module that lets you easily add a site search to your application using swish-e (http://www.swish-e.org). We've already used it's predecessor on a pretty large project and it worked rather well as a base class (but for most cases it can probably be used as-is). This is great! This is a really useful module that I could see myself using. I will have to check it out. If I may make a suggestion for more functionality: How about a run-mode to show the results with terms highlighted, a la Google? -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] OT - YAPC::NA 2005
Steve Comrie wrote: http://yapc.org/America/index.shtml Speakers haven't been announced yet (the call for submissions just passed). But I was wondering if anyone on the list was planning on or thinking about going. I'll be there... don't know if I'll be speaking or not :) Looks like you will be speaking, according to the schedule: http://yapc.org/America/schedule-2005/day3.html I'd love to go, but I have a schedule conflict. My wife is due to give birth to our second child on June 28. That pretty much means I have a no-fly zone from last week of June to first week in July. ;-) Good luck to all the CGI-App speakers! Post the news of your talks back to the list. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] In need of suggestions. . .
Hi Jason -- I need a way to pass parameters between the scripts. The logical choice is through the user's session, but that makes more than a few places that I would have to check to clear the message field if it is not needed. Is there something simple I'm missing? (That is certainly the same question I would ask -- stress on the simple part. I am a fan of simplicity.) Unfortunately, I don't have a more simple suggestion for you. The ability to send messages between requests, screens, or cgi-apps is a tough one. In the last couple years the best system I've used has been the architecture devised by Sam Tregar, built on Apache::Session. It works in essentially the exact manner you describe -- messages are pushed into the user's session, and are then pulled out on the next request and displayed on the top of the page. The only improvement I can suggest is that you centralize the display of messages in a Perl module. For instance, you might create a CGI-App super class and override load_tmpl() to put pending messages at the top of the page. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Persistent $app object in mod_perl
Hi Chad -- I'm thinking of using CGI::Application in a new project with mod_perl, and I know the two work together quite well... But I've only seen it done where the application object is instantiated and run at the same time from within the handler. This isn't the most efficient way to do it when using mod_perl. What I would like to do is instantiate the object in the body of the handler's package, and reuse it over and over by setting the r parameter and calling $app-run(), like this: That is not the way CGI::Application works. The CGI-App object expects to have a lifespan of exactly one request. You refer to efficiency, and mod_perl. CGI::Application was developed from the start to work efficiently with mod_perl. Using Apache::Registry, the code is efficiently cached, so very little unnecessary work is done between requests. If you believe there is any other inefficiency, please provide dprofpp profiling data to back up your theory. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Preview Release available with callbacks code integrated
Hi Mark --
I think I spent more time 'on the fence' about integrating callbacks
into the core than anyone. So I thought it would be worth
explaining my
thinking about accepting the patch now.
I took a look at the proposed docs, and I do have a question:
$self-add_callback('prerun', \callback);
$self-add_callback('teardown', \callback, 'FIRST');
Why couldn't this same effect be accomplished via sub-classing and
overriding functions, just like load_tmpl()?
-Jesse-
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] JOB: senior Perl developer (New York City)
Hey All -- I'm looking for an extremely sharp Perl programmer for a highly dynamic web application project. This is probably a contract position for a couple months, but possibly something more permanent. Short list of technologies and techniques: CGI::Application (naturally!) HTML::Template DBI MVC design Linux development CVS If you're interested, please email me with a resume and desired salary/rate. Thanks! -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CAP::Apache and CAP::Session
Hi Michael -- + speed - yes I know that in some circumstances CGI doesn't perform that badly under mod_perl since it doesn't need to be loaded again. I also know that a web application typically has other bottle necks besides parameter parsing and cookie generation (like database connections, large queries, etc). Even knowing this, If all I'm doing is using the Apache::* modules for dealing with parameters and cookies, why not use the solution that is faster. If that's all you're doing, naturally, go for it. The problem is when you need some of those other features. You can always throw more hardware at it right? But if with a simple decision to not use CGI.pm can be made and I can squeeze even just a couple of drops more out of my app why wouldn't I? I don't think that it's not that much faster is a valid argument in and of itself. Not in and of itself. But it's not that much faster becomes a highly valid argument when you need features in CGI.pm, or your developers are already very familiar with CGI.pm and you're on a schedule. In that circumstance, switching to an environment with a learning curve because it is only very slightly faster (but much more geek chic) is a luxury. + size - CGI.pm is a very large module (as others have pointed out just recently) and by not using it at all I save myself memory. This again would help in high performance situations. Not as much as you think. If you're pre-loading CGI.pm at Apache startup, the memory is shared between child processes. + more access to apache - I agree that in most typical situations all you do in a C::A is content generation. But I can think of other situations where it would be nice to have a more direct access to the apache API. I can too. That's why I'm a big advocate of writing Apache modules for authentication and authorization, rather than putting it in your (CGI) application code. But the way I look at the architecture, Apache modules are in a layer separate (and orthogonal) to the CGI application layer. (The Apache team also envisions it this way. That is why there are separate request phases in the first place.) If you use mod_perl properly there is no reason why you'd want to make changes to the logging mechanism anywhere BUT during the logging phase -- IOW, far from your CGI application request phase. And the separation is more than architecturally. It is staff-wise, as well. You can find more programmers familiar with CGI.pm than Apache's API. Apache-savvy developers, such as yourself, can write sophisticated custom handlers, and more junior CGI developers can do all the heavy lifting. Unless your org likes to pay for all senior developers, most orgs would prefer to have a small number of specialists, and a larger number of (less expensive) developers for the day-to-day work. And one more thing: If you develop in API space, you probably have to restart Apache every time you make a change. Wouldn't it be infinitely easier to be able to start Apache in a development mode which causes your apps to run as CGIs, and then flip back to production mode to gain mod_perl performance without having to change one line of code? I've been doing exactly that for years by using CGI.pm + Apache::Registry. (Restarting Apache after every change is only slightly less irritating than recompiling. If I wanted to recompile all the time, I'd use Java.) I just think that it hampers the adoption of C::A for some when becomes difficult to use the apache API. Interesting point. Maybe you're right, but I've had this conversation many times over the years (here, and on the mod_perl mailing list), and whenever I corner someone and ask them which features of the Apache API they want at CGI-runtime, they come up blank. Once they acknowledge that things like logging, authentication, and authorization are better handled as separate (non-CGI) modules, the main motivator for developing directly in the Apache API becomes a matter of preference and a penchant for the more fashionably cool bleeding edge. Apache::Request has made it MUCH easier to develop in API space for non API-savvy coders. But if they're not API savvy, what are they doing here, anyway! TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CAP::Apache and CAP::Session
Hi Cees -- OK, I'll switch it to use CGI::Cookie directly instead of using it through CGI.pm. I'll try and get this out soon, but patches are always welcome. Before you go and modify your module, shouldn't the responsibility for providing a working cookie() method be on CAP::Apache? I write in the CGI-App pod, regarding using an alternative to CGI.pm: ...your query interface must be compatible with CGI.pm, or you must wrap your chosen query interface in a wrapper class to achieve compatibility. Michael: If you want to use something besides CGI.pm, why don't you make a wrapper class which is compatible with the former? I'm quite certain that the cookie() method isn't going to be the only non-compatible feature of your approach. I'm also quite certain that Cees' module is not going to be the only CGI-App plug-in which assumes (as CGI-App does) that you're using a CGI.pm compatible interface. Rather than push the responsibility for choosing a different interface onto other module authors, why don't you deal with it yourself? Regarding the use of CGI::Cookie -- I think this is a violation of encapsulation. What if some other module author plays by the rules and creates a CGI.pm compatible wrapper? Cees' module won't use it, and the wrapper won't work as a result. It doesn't seem fair to penalize authors who actually want to play by the rules, does it? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CAP::Apache and CAP::Session
Hi Cees -- Good to hear from you again. We've missed your input here in the last little while. Lol... You guys seemed to have everything so well in hand, I didn't want to mess it up! The part I was planning to alter was the creation of a new cookie. This only currently uses $self-query since it is convenient, but it could easily use CGI::Cookie directly without breaking encapsulation. All that really needs to be done is for this to send a valid formated cookie string to the header_add method, so it doesn't really matter how the string is built. I get what you're saying, but if its really that simple then Michael can write his own cookie() method. I'm imagining that one day someone might want to create a CGI.pm work-alike for WAP or something which has a different format for cookies. This would keep it simple. The section that looks for the current session ID in the cookies and/or GET/POST params will still have to use the $self-query-cookie and $self-query-param methods, since as you mention that would be the expected behaviour. Sounds like we need Michael's cookie() method anyway, right? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CAP::Apache and CAP::Session
Hi Michael -- The main reason I didn't do this was because the CAP::Apache wasn't a wrapper around Apache::Request, but a plugin for C::A. That's correct -- it's not a wrapper. But you're trying to cram an Apache::Request peg into a CGI.pm-shaped hole. As the IBM commercial goes, You're going to need an adapter. And since you're the one doing the cramming, seems to me that you ought to write the adapter/wrapper. I was just trying to help people to be able to use as many plugins as possible with CAP::Apache. This may not be possible though. A laudable task! You've done half of the job by creating CAP::Apache. Now you have to do the other half and create a compatibility layer between Apache::Request and CGI.pm. They are pretty similar, but not the same. I think it would also be breaking encapsulation if my plugin added methods (such as 'cookie' or 'dump') to the Apache::Request namespace. I'm also not convinced that a wrapper is the best solution either since you would then have two interfaces for the same thing to keep in mind while programming. Ideally I wanted to allow users to be able to directly use Apache::Request, not something else. I think you have two different desires in conflict here: 1. To use Apache::Request 2. To have it work just like CGI.pm Apache::Request isn't CGI.pm. It can't do all CGI.pm functions without your help. Personally, I think a subclass would do the trick nicely. I can see it now... Apache::Request::CGIpm Maybe I just need to petition the libapreq people to add a cookie method to Apache::Request. If you're going to petition them for anything, you should ask them for full CGI.pm compatibility. That seems to be their desire, at any rate. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] passing serveral pages onto one main menu.
Hi Frank --
I'm putting in code like this:
my $which_query = $form_parameters-param('which_query') ||
'nothing';
Have you noticed the similarity between the which_query and the
run-mode param (rm)? Both change the major functionality of the
request. In effect, they are doing the same thing.
If you are committed to your current path, I'm sure you'll make it work
eventually. However, you might want to consider folding which_query
into the run-mode mechanism, creating modes such as save_muncipality.
This will give you all the benefits of CGI::Application without having
to rewrite most of its functionality.
Anyway, is it possible to use return $self-main_menu(); to
redirct to
the main menu runmode and pass though the fields and stuff
relevant to
keeping the app from returning the start_mode
That is the recommended way of handling the situation. For example:
sub save_muncipality {
my $self = shift;
# Validate the form data. Return user error if necessary
return $self-edit_muncipality(Bad input data)
unless ($self-muncipality_formdata_is_valid());
# If data is OK, save it to the database
$self-save_muncipality_to_database();
# Return user to main menu with message
return $self-main_menu(Muncipality saved);
}
This is a somewhat naive example but, as you can see, returning the
output of another function (even a run-mode) is valid. You can even
pass data into those functions (such as human-readable messages, as in
this example).
Warmest regards,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Mail archive broken
Hi Dan -- I'm after a message sent to the list a couple of days ago (it's on my home computer I'm at work). I went to the archives (http://www.mail-archive.com/[EMAIL PROTECTED]/) but the latest message seems to be dated 7th October. I can't explain why mail-archive.com didn't get the latest messages. There is a second list archive available which is also linked in the message footers. GENERAL LIST ADMIN NOTE: I am migrating to a new server. This migration will also change the mailing list software to Mailman (http://www.list.org/). You will all be notified when the switch-over happens. FYI, the reason for the list software switch is because I'm switching SMTP servers from QMail to Postfix. TTYL, -Jesse- - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Hybrid static/dynamic site
Hi Joel -- I'm working on a web site that will be a combination of static pages and application pages, and I'd like to use cgiapp to build the static pages. I've been browsing the archives, and can't find any real answers. Should I be considering a separate utility or CMS based on HTML::Template? Stepping back a bit: Why do you want CGI-App to build static pages? Possible reasons that come to my mind: * You're trying to implement site-wide login security. * You have global parts (navigation, etc.) which you want included in each page. In the first case, if you have the means I would strongly recommend you use an Apache module-based auth system, instead of putting your security into your application. This will protect all documents, othogonally to the content served. In the second case, you could use simple server-side includes. However, I can see the benefit of using one template system throughout. If this is your goal, then this isn't really a CGI-App question so much as a question for your templating system. If you're using HTML::Template (the default template engine for CGI-App) I would recommend writing an Apache module which handles any file in htdocs which ends .tmpl. If you do not have the means to write an Apache module, that is when you need a script to drive your template engine. Some other people have referred to such a script for Template-Toolkit. I've never seen it before, but writing such a script for HTML::Template should be trivial. You could use CGI::Application, or you could do something even more low-level. All the script has to do is to is to look at the requested URI, load the appropriate template file, and populate it with the appropriate data. TTYL, -Jesse-
RE: [cgiapp] Hybrid static/dynamic site
Hi Tim, Joel -- If you're ok with going the somewhat commercial route I've used Movable Type in this scenario which is for all intents and purposes a CMS. Its template engine is not optimized for dynamic generation though. It does use HTML::Template for its own application templates. With the smart use of includes and a shared stylesheet it can be pretty seamless. I hadn't through that Joel would want to statically render the site. (I got the impression from his original message that he didn't want to serve static pages.) If he doesn't mind statically rendering pages, but just needs a dynamic way to do so, then MT would work. If your content management needs are more sophisticated, you could also use Krang: http://krang.sourceforge.net/ It's free (as in freedom, AND beer), all Perl, uses HTML::Template, and was written in part by a few people who are regulars on this list. ;-) TTYL, -Jesse-
RE: [cgiapp] Structuring my C::A
Hi Jason -- My C::A has two modes: search and query. Each mode produces a web page consists of one or more tabs. In search mode (for example), each tab collects some information from the user, then combines that data into a database query. The way I would handle the problem is to make each tab a separate run mode -- or possibly each tab is a separate CGI-Application module. If you tell me what the tabs are for I can give you a more specific solution. By the sound of it, search and query (don't they usually mean the same thing?) are probably not your run modes -- definitely not your only run modes. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::App ported to Python
They say imitation is the highest form of flattery. Or something like that: CGI::App ported to python http://thraxil.org/code/cgi_app/ Fantastic! The cult spreads. Congrats to Anders Pearson. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Planning next CGI::App release
Hi Cees -- One thing I am still waiting on before I go ahead is a response from Jesse for his blessing to use the CGI::Application namespace for this module. I sent him a private email asking permission a couple of weeks ago, but it probably got lost in the multitude of mail he must get. By all means, go ahead! If I may recommend a name, have you considered CGI::Application::PlusPlus? ;-) TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Re: CGI-App and Apache::Request (replacing the instance script)
Hi Chris -- Your comments were wholy negative regarding mod_perl and the 'cadre' of mod_perl zealots, so I was left to guess your motive. I guessed poorly. I was not referring to a 'cadre' of mod_perl zealots. I'm a mod_perl zealot! And I would like to imagine that I'm part of that particular cadre. I was referring to a cadre of zealots who insist on writing web-apps in Apache handler-space. Those guys are nuts. IMHO, handler space is perfect for writing Apache API handlers -- IOW, things which actually require direct access to the API. (Authentication, Authorization, special content handlers, special logging handlers, etc.) Web-apps don't need run in handler space to gain the benefits of mod_perl (see Apache::Registry), and developing them there is a major pain in the ass. Besides the logistical difficulties (such as having to restart the server constantly), there haven't been a lot of high-level tools. That is, until Apache::Request. Apache::Request is attempting to be to mod_perl what CGI.pm has been to web-apps. Apache::Request is fast, but it is (thus far) incomplete. Nonetheless, the speed advantage and its popularity is compelling enough to discuss supporting it in CGI-Application. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Re: CGI-App and Apache::Request (replacing the instance script)
Hi Chris -- VENT venomous=1 I think there are some programmers that are just afraid of mod_perl. Too bad they have to make nasty jabs at those of us who aren't. /VENT Your comment indicates short-sightedness in an insulting way. Lol... I've been using mod_perl since at least 1997. I've written tons of Apache handlers to do very complex tasks; not just *simple web applications*, but tasks which *actually* need the functionality of the Apache API. My credentials speak for themselves. *Afraid* of mod_perl? Not likely. Past being *infatuated* with it? Absolutely. Most programmers get infatuated with a new technology when they first learn it. After a while they find out what it's good for and what it's not so good for, and then the real useful work can begin. Mod_perl is the greatest thing since sliced bread for Apache, Perl and web-based applications. There are many ways to use it. If you're rebooting your server every time you make a change it's because you've not figured out how to get around this issue and still use mod_perl (or you don't understand Apache::Registry). Nearly 100% of my development is mod_perl based, and my dev team doesn't have to save-restart-refresh every time they make a change, yet we still get the full benefit of mod_perl. And we don't have to do one thing in development and something different in production. The only argument I've heard (here or on the mod_perl mailing list) which holds any water is that Apache::Request is measurably faster than CGI.pm. I've seen a benchmark, and it's significant enough to be worthy of consideration. What we're talking about here is how to integrate Apache::Request into CGI-App. Regardless of whether I think *.pl files are convenient, a system has to be devised to allow meta data (i.e.: Location and run-time parameters) to be set, as they are set now via instance scripts. If you have any suggestions, throw them out. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ANNOUNCEMENT -- CGI::Application v3.21
I see my short patch to run() did not make it into 3.21. Any idea when it will be applied to official C::A, Mark? Thanks Josh -- I'll make sure it's in the next release. -Jesse- - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] CGI-App and Apache::Request
Hi Mark -- I have questions about a couple of items on your CGI::App TO DO list. One was better support for mod_perl by supporting Apache::Request. I'm just starting to use mod_perl, so could you give me an idea of what's involved here? The idea here is to allow CGI-App to use Apache::Request instead of CGI.pm. The reason is because Apache::Request appears (in some benchmarks) to outperform CGI.pm significantly. And Apache::Request has some die-hards. I don't want to continue to turn off hard core mod_perl-ers because they don't like CGI.pm. Could it be implemented as a smart feature, so that if a mod_perl environment is detected, Apache::Request is used? Or, perhaps it should be a simple sub-class (Apache::Application), that simply overrides the query method default? It almost like a waste to have an entire module for something that simple. It could be done either way. I consider mod_perl a significant part of the market for CGI-App, so it's not necessarily a bad thing to include it. However, I'm inclined to release a Apache::Request version as a separate module because some CGI-App/mod_perl users may still not want to muck around with Apache::Request -- it's not a drop-in replacement for CGI.pm. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Re: CGI-App and Apache::Request
Hi Bill-- And/Or: my $foo = Foo-new; # provides param() and header() methods [...] query_provider = $foo, That's already supported: my $query = CGI-new(); my $app = My::App-new( QUERY = $query ); Back to integrating with mod_perl: One other thing about a hook into Apache::Request -- there are two points of interface. We've only been talking about the query object. There is also the point at which the application is called. We need a replacement for the instance script. In regular CGI-style CGI-App modules, you have a file my_app.cgi: #!/usr/bin/perl -w use My::App; my $app = My::App-new(); $app-run(); In a pure mod_perl environment, this would have to be implemented via the httpd.conf or .htaccess file: PerlHandler My::App I'm happy with that interface. CGI-App could simply implement a handler() method which constructs and runs CGI-App. Also, we need a method, via Apache's config interface, for setting run-time parameters. In an instance script we pass in a hash, like so: my $app = My::App-new(%my_config); There is no such opportunity to pass in live Perl data via an .htaccess or httpd.conf file. We need an alternative. Any suggestions? The emphasis should be in intuitiveness for Apache administrators. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] ANNOUNCEMENT -- CGI::Application v3.21
Hi All -- Version 3.21 of CGI::Application is now available via CPAN! A special thanks to Mark Stosberg for accepting the yoke of co-maintainer -- a title whose glamorous duties for this release included collating multiple submitted patches, coercing CVS to behave properly, testing, and uploading to PAUSE. Thanks Mark! Download site for CGI::Application: http://search.cpan.org/dist/CGI-Application/ CHANGES SINCE VERSION 3.1: - header_add() has been added to allow setting extra headers, particularly cookies, after header_props has already been called (Cees Hek, Mark Stosberg) - CGI::Carp is now optional. See docs for details. (Steve Hay) - Avoid 'unitialized value' warning on redirects (Cees Hek) - Some tests added (Mark Stosberg) - Updated documentation to use term Run Mode consistently, versus Run-Mode with a dash. Run-mode-with-a-dash is dead. Don't revive it. Also added mentions of the CGI::Application wiki and CGI::Application::ValidateRM (Mark Stosberg) - Fixed typo in cgiapp_postrun documentation (Steve Hay) - Improved exception handling (Steve Hay) - delete() method added to remove items stored using param() (Michael Peters) - 'CGI_APP_RETURN_ONLY' environment variable that is used for testing is now documented (Michael Peters) - dump_html() is now properly HTML-escaped (podmaster, Brian Cassidy) - Migrated from Makefile.PL to Build.PL. Either can now be used for installation. - Updated 'Changes' file to put new releases on top. Read the article Using CGI::Application on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run Modes. Each Run Mode is roughly analogous to a single screen (a form, some output, etc). All the Run Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Randal Schwartz writes about CGI::App alternative
Hey Mark -- In this article Randal describes his own technique for a CGI application framework. He mentions evaluating and passing over CGI::App. I wish he'd said more about why. He says: CGI::Application looked close, but had more knobs and dials than I needed, and yet not enough custom hooks either. And possibly related, consider this thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg35227.html I never did get a reply to my message to him: http://www.mail-archive.com/[EMAIL PROTECTED]/msg35270.html At any rate, according to Randal, if you're looking for fewer knobs and dials, but more custom hooks, you should look elsewhere. (May I recommend CGI::Framework::Contradiction?) TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::App 3.2_mls5 available
Hey Mark -- I'd like to revive the idea that someday CGI::App 3.2 will be formally released. :) To that end, I have a prepared a proposed release, with the help of several others. It's here: http://mark.stosberg.com/perl/CGI-Application-3.2_mls5.tar.gz Downloaded it. Looking at it now! -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::App 3.2_mls5 available
Hi Michael, Mark --
I would like to revive an idea that presented a while back
concerning a
'delete' method very similar to CGI's delete method. It would
simply remove
something from the internal '__PARAMS' hash. A simple
implementation could be
as follows...
sub delete
{
my ($self, $param) = @_;
delete $self-{__PARAMS}-{$param};
}
Wow... I never thought such a small feature like storing a bunch of key
value pairs would become significant enough to warrant complete
functionality. But, there you go...
I'm a little concerned that we're building out functionality which is so
minor, but if you want it my only strong consideration is that you do
not call it delete() -- too common.
Another change that I would like to see is to move the
undocumented (and thus
unsupported) feature of the $ENV{CGI_APP_RETURN_ONLY} into a
documented and
supported state.
Agreed, particularly for the reason Mark talks about:
I definitely agree that either this should be documented or
their should
be some other mechanism to allow for automated testing.
It would be nice to have a standard mechanism for testing. My biggest
gripe with PHP (with which I've recently had an opportunity to become
more familiar) is the serious lack of test-able structure, or even a
culture of QA. More test-ability is a good thing. Maybe someone can
even release a testing module for CGI-Apps which builds on one of the
popular systems.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] RE: CGI-App configuration file
Hi Eugene -- Thanks for the inquiry regarding CGI-App. In the future, please post queries about CGI-Application to the mailing list, to which you can subscribe by sending email to: [EMAIL PROTECTED] This message has been cc'd to the list for the benefit of the members. it would be nice if it had a configuration file, like java struts does, or like php.mvc does. CGI-Application does have a configuration file, of sorts -- the *.cgi file instance script. This file can pass arguments to the application module at run-time to configure application behavior. I'm not sure what you're talking about when you say like java struts does, or like php.mvc. Perhaps you can explain the specific features you're looking for. IMHO, configuration files are a slippery slope. They tend to start off simple, and rapidly get complicated. Ultimately, they become their own mini-languages. The ultimate proof of this: sendmail.cf. (Yes, the cf stands for configuration file). In lieu of some separate file in a homegrown language, I prefer putting configuration data into: * Class modules (*.pm) * Instance scripts (*.cgi) * Database tables All of these resist the movement towards mini-languages. They all also use languages and systems which are already in use, thus reducing complexity. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::Application::XML
Hi Jason -- Of course, you could override the cgiapp_postrun(), in CGI-App-XML; and then add the serialize() function. But, then the user of the module can't use the cgiapp_postrun() hook without destroying the XML serialization. I don't think this is a real problem. That's what the hook is for! If you're concerned, and want the user to still be able to use a hook like postrun(), just add one! In your cgiapp_postrun(), add a call to cgiappxml_postrun(), and document it in the POD. HTML::Template is nice but XSLT is nicer :). XSLT strength comes from it's abliity to tranform structured XML data into another form of structered XML data. Not simply replacing text with text. I don't agree with you there, but that doesn't mean you shouldn't release your module! XSLT is fine if you have to transform XML into XML. HTML, however, is all about creative design. Designers don't know XPATH, and never will. Their tools are HTML and CSS. The purpose of HTML::Template is to give the designer power to change design WITHOUT a programmer. If your templating interface is XPATH, then your designer needs to work with an XPATH programmer. If you're going to have your designer work with a programmer, then you're right back to the awful state of things in the world before templating systems were designed. IMHO, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::Application::XML
Hi Josh -- How is this an improvement over CGI::XMLApplication? Can you get your improvements into C'XA so there isn't a code fork? If there is some reason to not use CGI'XA in favor of C'A'X you should really document that in your pod and provide the pros and cons for each. IMHO, the author of CGI::XMLApplication should have used CGI::Application in the first place. CGI::XMLApplication is just CGI-App which outputs XML destined for XSLT. It implements a CGI-App style state machine. (The fact that CGI::XMLApplication uses call-backs is not important. CGI-App used to use call-backs, but we evolved to support references by name in addition to call-backs.) As Jason has proven, slapping XML output on CGI-App is easy and clean. Jason: If you haven't already, you should release your module to CPAN. I think it makes a lot more sense than CGI::XMLApplication. I believe it will have a built-in user base of CGI-App users. It will be far more appealing than CGI::XMLApplication, which is a bit of a one-trick pony and an unsupported dead-end, IMHO. Before you release it, I would do a couple things: * Improve the interface to better integrate into CGI-App. For example, use the cgiapp_postrun() hook to automatically create XML or HTML via XSLT. * Write POD! Don't forget to include example cases. * Write tests, and set up a real MakeMaker-style CPAN package. Not that you need it, but you have my blessings to use the CGI::Application::* namespace. I think you could have a winner here. When I read about CGI::XMLApplication a few months ago I nearly wrote the same thing. The only reason I didn't is because I don't use XSLT. ;-) HTML::Template rocks. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::Application::XML
Hey Darin -- IMHO, the author of CGI::XMLApplication should have used CGI::Application in the first place. No bias here. ;- Lol.. And this, I think, is where many users have wished for C::A to be separated from H::T. Then it would make much more sense to graft XML, H::T, Text::Template, etc., in subclasses: Sub-class, by all means. But that shouldn't mean that the parent class is useless! Think of it as a default. In lieu of a more specialized sub-class, CGI-App uses CGI.pm and HTML::Template. The hooks are already there. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] concerns with new header_props
Hello all --
Cees, Mark, and I are in a conversation regarding changes to the
functionality of header_props() in version 3.2. Before I reply to Cees'
message, I wanted to forward it to the list to get your input.
-Jesse-
-Original Message-
From: Cees Hek [mailto:[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 9:32 PM
To: Jesse Erlbaum
Cc: 'Mark Stosberg'
Subject: RE: [cgiapp] concerns with new header_props
Quoting Jesse Erlbaum [EMAIL PROTECTED]:
Hi Mark, Cees --
I think this conversation should go on the list, if you're not
opposed.
I have no problems with this discussion going to the list.
Regarding the cookie functionality: I would rather not fix problems
in
CGI.pm. That said, how does CGI.pm handle this situation? If I call
$query-header(-cookie={...}) multiple times does it aggregate your
cookies? If not, than it's not a CGI-App problem -- it's a CGI.pm
problem.
The CGI.pm header() function is a onetime use function. It doesn't
store the
headers, it will return the requested headers immediately including any
extra
required headers to make up a valid request. This is not so much a
problem with
CGI.pm as it is more a design decision that made sense in a function
based module.
The existence of the header_props and header_type methods in C::A shows
that it
already had special functions to deal with this 'limitation' of CGI.pm.
This is
because the part of the program that prints the headers is not the same
part of
the program that decides what the headers should contain (ie what the
content-type is, or whether we redirect, or what cookies need to be
set).
I believe that since we already need the ability to cache the headers in
C::A,
we should make it flexible enough to allow the headers to be changed at
multiple
stages of the request.
A good example of the need for this comes from one of the driving forces
behind
CGI::Application, which is to build reusable code. If someone built a
standard
authentication module for CGI::Application, there is a good chance that
this
code will need to set a cookie. There is currently no good way to do
this with
CGI::Application, since this code would be required to call header_props
to set
the cookie, but those headers are almost guaranteed to be clobbered by
the rest
of the program (ie when the code decides to set the content type).
A very quick bit of psuedocode to illustrate this:
package My::Base;
use base CGI::Application;
sub cgiapp_prerun {
my $self = shift;
# Do the authentication and set a cookie if needed
if (no cookie yet) {
$self-header_props(-cookie = $cookie);
}
}
package My::App;
use base My::Base;
sub cgiapp_prerun {
my $self = shift;
# Make sure we run the cgiapp_prerun mode in our parent class
$self-SUPER::cgiapp_prerun();
# Turn off caching (will clobber the cookie that was set earlier)
$self-header_props(-pragma = 'no-cache');
}
sub my_image_runmode {
my $self = shift;
# Return an image
# Change the content type (clobbers the pragma header)
$self-header_props(-type = 'image/png');
return \$the_image;
}
I don't see this example as being that unlikely, but it is imposible to
do
without caching the headers somewhere. The header caching code could be
added
to the My::Base class and then a cgiapp_postrun method could send the
collected
headers to header_props, which will then turn around and pass them to
CGI.pm...
That just seems like unnecesary complications for such a simple thing.
Now the talk we had about needing a way to handle multiple cookie
headers fits
right in with this problem. The above example could easily be expanded
to
include 2 locations where cookies need to be set.
Perhaps a change from 'add_cookie($cookie)' to header_add(-cookie =
$cookie)
and header_set(-cookie = $cookie) would be more palletable. This would
give
user the ability to overwrite a single header, and also add a header to
the
current list. That would abstract the interface to not include anything
specific to any given header.
header_props - works as is
header_add- add a header of this type to the current list
header_set- replace the current header of this type
I would suggest that header_add and header_set only accept one header
type, and
then a scalar or arrayref of header values. This should have zero
impact on
existing code, and would make working with headers much more flexible.
Going
back to the psuedocode above, replacing the calls to header_props with
calls to
header_[set|add] would allow the program to work as expected.
Sorry about the length of this post, but I tend to get a bit verbose
sometimes :)
Cheers,
Cees
-Original Message-
From: Mark Stosberg [mailto:[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 1:43 PM
To: Cees Hek
Cc: Jesse Erlbaum
Subject: Re: [cgiapp] concerns with new header_props
On Sat, Nov 08, 2003 at 05:10:26AM +1100, Cees Hek wrote:
Quoting Mark Stosberg [EMAIL PROTECTED]:
I think I like
RE: [cgiapp] Cookies and mod_perl
I'm not sure what happened, but it just started working. Did you restart the web server? Because CGI-App uses Perl modules (as opposed to scripts), updates don't always take effect until you restart. -Jesse- - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Re: Template Toolkit Interaction
Hi Mark -- The patch idea makes sense to me. I suppose someone could start distributing a renegade patched version that just uses Carp. It does seem simple enough to allow a patch that makes it an option. I'll put in a patch in the next release, particularly if someone sends me one. I've been moving this week, but I'll do the release as soon as I get some Internet access in my new digs. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] C::A and mod_perl handlers
Hi Chris -- But for everything I have server control over I never develop on the production site. (If I do it's a change I have absolutely no fear of working the very first time. And a quarter of the time I still wish I had played with it on the development site first.) So nearly all development I do is on CGI on a seperate vhost or a seperate server all together. I never have to touch the apache configuration to go from development mode to production mode. This is a very separate issue from using Registry verses an ad hoc handler, but an important one. When I described making a simple change to the Apache configuration, I was really simplifying my usual development environment for the purpose of discussion. In practice, I never edit the httpd.conf. In fact, I don't even maintain one in CVS! What I do maintain is an httpd.conf.tmpl -- a template file from which an httpd.conf is generated when the server is started. A controller script handles generating the httpd.conf and starting Apache. The actual switch I'm talking about is actually implemented as an environment variable: CGI_MODE. IOW, if I want to test applications using mod_cgi I do the following: # CGI_MODE=1 apache.init start To test in Registry mode: # CGI_MODE=0 apache.init start Or more simply: # apache.init start The httpd.conf.tmpl (which is, as you might expect, an HTML::Template file) would have a block like this: FilesMatch ^.*\.pl$ TMPL_IF CGI_MODE SetHandler cgi-script TMPL_ELSE SetHandler perl-script PerlHandler Apache::Registry /TMPL_IF /FilesMatch I think it's very important that no changes be required to move code from development to production. Any system where you have to make changes to the configuration when you want to make a release live is anathema: It effectively throws away all the effort which went into testing an application. Every one of my developers has their own separate development server for each project. Development is 20% writing code and 80% testing code. If you test and test and test, and then make a change, you have to re-test (regress) everything. The variable parts of a system must be separated from the invariant so that it is not necessary to re-test your entire system -- particularly at the most critical moment -- when code has just been made live. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Thinking about constants and different uses of params
Hi Mark --
I'm interested in discussing suggested ways to best use PARAMS in
CGI::App, especially regarding the distinction between those that come
from a config file, an those that are declared in the
instance script.
[...snip...]
Do other people have config/param handling systems they are
particularly
satisfied with?
For configuration file params (to use your idiom), I tend to use Perl
modules:
package Site::Configuration;
use constant SMTP_SERVER = localhost;
...and in my CGI-App:
package Site::MyApp;
use base qw/CGI::Application/;
use Site::Configuration;
my $smtp_server = Site::Configuration::SMTP_SERVER;
This allows me to put more functionality into my configuration:
package Site::Configuration;
sub SMTP_SERVER {
if ($ENV{DEVMODE}) {
return localhost;
} else {
return smtp.site.com;}
}
As you can see, this change would be completely backwardly compatible
with any code which was written to use it. The configuration methods
could be as dynamic as you like -- they could connect to a database and
retrieve configuration, read it from a file, etc.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Re: Thinking about constants and different uses of params
Hi Mark --
Another question: Do you store Site::Configuration in the perllib
directory with the other perl modules? I found this made site
launches a
little more difficult, because I would want to copy
everything but the
Config module to the live site, which have an existing Config module
configured for the live site. Instead, I store a config file in a
config directory.
Perhaps you solve this with the if $ENV{DEVMODE} construct you
illustrated above.
I definitely store Site::Configuration along with all the other
modules.
As you've identified, I use a mechanism similar to my if $ENV{DEVMODE}
example to automatically change the run-time configuration. The system
I use is based on a few ideas:
1. There are things called environments, of which production,
staging, and Mark's development would be a few.
2. Each environment should have its own Apache server.
3. Environments need to be centrally managed.
4. The process for moving work between environments must be totally
consistent for Quality Assurance's sake.
5. Each environment is defined by a number of distinct run-time
settings.
Regarding number five, here is a list of run-time properties for
environments in my typical system:
ENVIRONMENT_NAME
DEV_ROOT
LOG_DIR
SITE_HOST_NAME
APACHE_IP
APACHE_ROOT
APACHE_PIDFILE
For each environment I have a hash containing values for these
parameters. A control script (run via sudo) is used to start and stop
Apache. This control script reads the environment name (e.g.,
production, mark, jesse, etc.) from a UNIX environment variable,
and selects the proper hash of environment configuration settings. This
control script then *dynamically* creates an Apache httpd.conf from a
template (using HTML::Template, of course) populating things like the IP
address and host name. (N.b., the DEV_ROOT property is used to
automatically set PERL5LIB and HTML_TEMPLATE_ROOT.)
As you can imagine, this system eliminates the problems usually related
to moving changes between environments. I've been using this system for
years.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] ANNOUNCE: CGI::Application 3.1
Version 3.1 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://search.cpan.org/dist/CGI-Application/ CHANGES SINCE VERSION 3.0: - Changed dump_html default run-mode to be referenced by name instead of sub-ref. This allows dump_html() to be overridden in sub-class. - Added current run-mode to output of dump() and dump_html(). (Thanks to Mark Stosberg for the suggestion.) - Added example of doing an HTTP redirect (suggested by Sam Tregar) - Fixed bug where non-CGI.pm query objects couldn't be set at initialization time via the new() method. (Thanks to Steve Hay for the catch.) - Added header_type(none) to suppress HTTP header output. (Thanks to Steve Comrie for the suggestion.) - Numerous typos corrected in POD. - Added cgiapp_postrun() hook. This hook allows run-mode output to be pipelined through optional filters, modifying the content and HTTP headers if so desired. Read the article Using CGI::Application on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] When is next version coming?
Hi Steve -- About a month ago you said in a mail to this list that you'd try to get 3.1 out this weekend, but it didn't happen, and hasn't done since either unless I'm missing something. Do you have a new ETA for 3.1? I'd really like to start getting to grips with the new post-run stuff. Sorry for the delay! Here's a link to the new release on my site, since it appears that PAUSE is down at the moment: http://www.erlbaum.net/CGI-Application-3.1.tar.gz I'll make a more formal announcement once the module is up on CPAN. In the mean time, everybody should let me know if they find any problems with the implementation of cgiapp_postrun(). Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ANNOUNCE: CGI::Application::Generator 1.0
Hi Benjamin -- * Create an XML DTD and a SAX interface to convert XML to a CGI::Application module. When doing this, the implementor should consider XMI[1] as an XML file format. This way UML tools could be used to create a model, that is saved into a XMI-file, from which in turn a CGI::App module could be generated. I'm imagining that different modules could be created to provide different interfaces. Someone could write interfaces for both XML and XMI, as well as anything else they can think of (Web, Tk, Win32 GUI, etc.). Think of it: Automatically generated perl apps, directly from a UML model. No more headstart for Java/JSP through the support of modeling tools. That's exactly what I was thinking! ;-) TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ANNOUNCE: CGI::Application::Generator 1.0
Hi All --
Version 1.0 of CGI::Application::Generator is now available via CPAN!
I've release an initial version of CGI::Application::Generator. This
does not include most of the (excellent) suggestions which came from our
discussion. Here is a list of the items I would like to implement in
forthcoming versions:
* Complete mode_templates() method, to associate specific templates
with a run-mode.
* Write shell() method to interview the developer and create a module
from interactive input.
* Create an XML DTD and a SAX interface to convert XML to a
CGI::Application module.
* Allow arbitrary data to be passed through Generator to the
underlying HTML::Template file. Through this mechanism, more
sophisticated applications might be dynamically created.
I wanted to specifically talk about this fourth idea. This is in
response to a specific comment by Cees:
One comment I have on the code it generates. I personally
don't like the fact that the Database connection is made
on every call. I quite often have a mix of pages that may
or may not require the database. I realize that I could
easily customize the app_module.tmpl template locally for
my own use, but I think it is at least worth bringing up.
Personally I would use something simple like the following
for database access.
This is both a potential performance issue, and a matter of style. I do
not claim that my template is right for every situation or company.
Instead of trying to come up with a one size fits all output format, I
would like to build in flexibility.
I think that one way to do so effectively would be to allow a data
structure to be passed into C::A::G, which will be directly passed into
the HTML::Template file on the other side. This would allow you to
develop a custom template which would be able to configure arbitrarily
sophisticated output.
I would be interested in discussing this with all of you, in order to
devise an interface which will permit sufficient control. One idea I
have is to provide three configurations for application specification to
control the specification of the use modules scope, run modes scope,
and package-level scope:
# Use-modules scope
$cag-use_modules(qw/My::DBICreds My::Utilities/);
$cag-use_modules_additional_data(
My::DBICreds = {import = []},
My::Utilities = {import = [qw/add_widget delete_widget/]},
);
# Run-modes scope
$cag-run_modes(qw/
list_widgets
add_widget
insert_widget
edit_widget
update_widget
delete_widget
/);
$cag-run_modes_additional_data(
list_widgets = {use_dbh = 1},
insert_widget = {use_dbh = 1},
update_widget = {use_dbh = 1},
delete_widget = {use_dbh = 1},
);
# Package scope
$cag-additional_data( add_content_handler = 1 );
What do you all think of this?
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ANNOUNCE BETA: CGI::Application::Template 0.01
Hi Mark --
First off, thanks for the feedback! I'm very interested in getting some
ideas before I put this module out to the world.
I would find this somewhat useful. I think the interface I
would like best would either be an interview on the command
line, or a web form that I just fill in.
That was one of my first ideas. I went with an API instead because I
thought those other things could be built upon this system. Someone
could easily write a Term::ReadLine based script to pose questions to
the user.
I would welcome any code contributions! I imagine that this might be
implemented similarly to CPAN's shell() function:
$ perl -MCGI::Application::Template -e shell
In some ways it feels inefficient because some things are
declared only once, so there's not time saved in automation
there. Some detail points:
- I was surprised you didn't use the new arrayref method of declaring
run modes.
I did, and then I switched back for two reasons: First, I didn't know
if the user would be using CGI-App 3.0. Second, I wanted to make the
output module more easy to adapt, if desired. Perhaps I'll change it
back.
- It would be nice to combine these common three rows of output code
into a single function:
open(OUTPUT, WidgetBrowser.pm) || die($!);
print OUTPUT $cat-output_app_module();
close(OUTPUT);
I thought about that, too. In the end, I chose not to write the file
because I didn't want to prevent someone from using this module in a
different way which didn't involve creating a file.
Perhaps this can be part of a the function of a shell() interface?
It seems like the most useful benefit here is creating the
stubs of the functions. Currently I handle this tedium with
abbreviations defined in my text editor, which makes this
fast, but also handles exceptions easier.
Currently I address this problemspace by having a template
project, which I duplicate and run a couple of regular
expressions over by hand to get it ready. This doesn't addres
the stub functions, though.
Yes -- this is the major motivation for me, too. The run-mode method
stubs which are created are really pretty much what I like to start with
when I write a new application:
sub run_mode_method {
my $self = shift;
my $q = $self-query();
my $dbh = $self-param('DBH');
return $self-dump_html();
}
I've also included stubs for POD documentation in each module. In the
stub POD I am advising on what I think should be included in any
CGI-App module documentation. Any thoughts?
FWIW, this module was inspired by two other systems:
1. h2xs - A good starting point for any Perl module. I wanted to
create something which would be a good starting point for a CGI-App
module.
2. Microsoft's visual studio products - Say what you want about
Microsoft, but their visual studio products are quite mature. I like
the way they automatically create a program stub when you begin. I
have, for years, imagined something which provides the same function for
CGI-App.
Thanks for your feedback, Mark!
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] ANNOUNCE BETA: CGI::Application::Template 0.01
Hi David --
I'm just having a look through your module to give you some
feedback. I notice
in the app_module.tmpl when you are writing the run modes
there is a variable
for mode_template but it isn't mentioned in your docs or in
the code. Is this
an unimplemented feature or have I missed something.
Not-yet-implemented feature. I wanted to get this in front of you all,
so I didn't finish it.
After just a quick look, I think I could probably use this
module. I would use
it in a macro in my code editor to start new applications.
The mode_template
function would be useful for me in this case.
In a nut-shell, I imagined a method through which you could define a
hash-table which would contain a map of run-modes to templates:
$self-run_mode_templates(
list_widgets = 'list_view.tmpl',
add_widget= 'detail_view.tmpl',
insert_widget = '',
edit_widget = 'detail_view.tmpl',
update_widget = '',
delete_widget = '',
);
Modes which don't have templates assigned would presumably be coded by
the programmer as to return the output of another run-mode upon
completion. These run-modes would be output by CGI-App-Tmpl like this:
sub delete_widget {
my $self = shift;
my $q = $self-query();
my $dbh = $self-param('DBH');
return $self-dump_html();
}
All run-modes with templates would be output like this:
sub list_widgets {
my $self = shift;
my $q = $self-query();
my $dbh = $self-param('DBH');
# Load HTML::Template file for this run-mode
my $t = $self-load_tmpl('list_view.tmpl');
return $t-output() . $self-dump_html();
}
What do you think?
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] ANNOUNCE BETA: CGI::Application::Template 0.01
Hi All --
I have a little module I've been working on, and I'd love to get some
feedback. You can download it here:
http://www.erlbaum.net/CGI-Application-Template-0.01.tar.gz
I made this to simplify the start-up process of making a new
CGI::Application-based module. If you can, try it out and give me some
feedback. In particular, I'm interested in a couple things:
1. Does it work? (Any bugs?)
2. Is it useful? Could you use this in your work?
3. Can the interface be improved?
Here's an excerpt from the POD:
START-
NAME
CGI::Application::Template - Dynamically build
CGI::Application modules
SYNOPSIS
use CGI::Application::Template;
# Required methods
my $cat = CGI::Application::Template-new();
$cat-package_name('My::Widget::Browser');
$cat-start_mode('list_widgets');
$cat-run_modes(qw/
list_widgets
add_widget
insert_widget
edit_widget
update_widget
delete_widget
/);
# Optional methods
$cat-base_module('My::CGI::Application');
$cat-use_modules(qw/My::DBICreds My::Utilities/);
$cat-new_dbh_method('My::DBICreds-new_dbh()');
$cat-tmpl_path('Path/To/My/Templates/');
# Output-related methods
$cat-app_module_tmpl('my_standard_cgiapp.tmpl');
$cat-output_app_module();
DESCRIPTION
CGI::Application::Template provides a means by which a
CGI::Application module can be created from code, as
opposed to being written by hand. The goal of this module
is two-fold:
1. To ease the creation of new CGI::Application modules.
2. To allow standardization of CGI::Application coding
styles to be more uniformly applied.
END
Thanks!
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] ANNOUNCE: CGI::Application 3.0
Version 3.0 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 2.6: - Changed run_modes() method to allow list of run-modes to be designated via an array reference. This will automatically create a run-modes table which maps from a run-mode to a run-mode method of the same name. Bumped major revision number to reflect this significant change in functionality. - Clarified license for module (GPL or Artistic). Included licenses in distribution package. Read the recent Using CGI::Application article on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::Application 3.0
Hi Darin --
The major change seems to be:
# Convert array-ref into hash table
foreach my $rm (@{$data[0]}) {
$rr_m-{$rm} = $rm;
}
It looks so puny when cast in the cold light of a diff! :-)
Yes, this is the most significant change in the new version. While the
code change is not very big, the new interface is:
$self-run_modes(
show_form = 'show_form',
add_thingy= 'add_thingy',
insert_thingy = 'insert_thingy',
edit_thingy = 'edit_thingy',
update_thingy = 'update_thingy',
delete_thingy = 'delete_thingy',
);
...Can now be said more simply:
$self-run_modes([
'show_form',
'add_thingy',
'insert_thingy',
'edit_thingy',
'update_thingy',
'delete_thingy',
]);
I updated the major version number because I wanted people to be able to
intuitively identify old interface versions from new interface version.
Of course, the new interface is fully backwards-compatible with the old.
Anyone want to start a conversation about its speed vs:
@$rr_m{@{$data[0]}} = @{$data[0]};
? No, didn't think so. :-)
Heh... I think I have a headache from reading that!
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] CGI::Application 3.0
Hi Jeff -- also, what if your run modes are outside of the main module. ie $self-row_modes( do_this = util::do_that() } The new interface for run_modes() does not prevent you from using the old interface. The purpose of this new interface is simply to speed along a very common use-case. If your coding style does not accommodate method names which exactly match run-mode names then you should continue to use the old-style interface. The old interface will never go away, so you should have no fear that code you've written will have to be changed. You shouldn't even feel a need to change the way you write your code in the future! Although this new interface suits my style of coding, I am not trying to encourage people to adopt this style. By all means -- feel totally comfortable continuing to do things as you have grown accustom. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] mod_perl and CGI::App
Hi Nate -- I have a few projects written with CGI::App right now. A couple of them are lower traffic sites but now a few of them are falling into the realm of performance intensive. I'd like to start using mod_perl for those sites. Someone said that CGI::App was written with mod_perl in mind, so I'm thinking this post is appropriate on this list. Yes -- CGI::Application was written with mod_perl in mind from the very beginning. If your code is written cleanly it should be a simple matter of activating Apache::Registry and setting it to be applied for your instance scripts. For example, I set all scripts that I want to run through Apache::Registry to end .pl (as opposed to .cgi) by adding the following to my httpd.conf: FilesMatch ^.*\.pl$ SetHandler perl-script PerlHandler Apache::Registry /FilesMatch That's it! All CGI::Application modules which are called by instance scripts which end .pl will now be cached in memory, and use the internal Apache Perl interpreter. Adding CGI-App modules to a startup.pl is not necessary, but it doesn't hurt. The only benefit will be on the first request to a particular application for a particular httpd child-process. The most important thing to add to a startup.pl, assuming you're using a database, is Apache::DBI. This will cause connected database handles to be cached, significantly speeding up applications which use them. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Global configuration
Hey William -- Thus I'm behind any effort that makes Perl more accessible to new users which is what I think a best practices document or faq can do for CGI::App and what the p5ee project could do for Perl modules in general. I would never badmouth any effort to try and help people get ahead on the daunting curve of figuring out which of the 5000+ Perl modules on CPAN are useful! That's not the goal of P5EE, at any rate: ...to promote the development, deployment, and acceptance of Enterprise Systems written in Perl. This isn't a training mission. It's a marketing mission. And I'm not against marketing Perl either, but this smacks of me-too-ism. Java has J2EE, so lets make P5EE. OTOH, what do I know? I'm all for anyone who wants to try and open the door to Perl, any way they think will be effective. If P5EE enables an IT staffer to convince their boss that Perl is a viable replacement for Java, that's great. As far as filtering for useful CPAN modules, I am all for an automatic rating system. I think a good first step would be tracking download traffic of modules. Download popularity is a pretty good indicator of something, me thinks. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Global configuration
Hey Peter --
I recently found interesting initiative, p5ee, which wants to be
enterprise-approved perl, like j2ee is.
They have list of CPAN modules they approve:
http://www.officevision.com/pub/p5ee/component s.html
Maybe they should list modules they *don't* approve. It might be a
shorter list!
Do they have marketing $$$ behind this idea? Without the bucks, J2EE
wouldn't exist. There is no Temple of the Enterprise Engineers to whom
to appeal for approval.
From my brief glance, P5EE seems like YAPPO -- Yet Another Perl
Programming Opinion. Maybe we should have a new CPAN hierarchy --
YAPPOx::, anybody?
Config::IniFiles is THE way for config, by p5ee guys. ;-)
On the subject of config files -- I've mostly used two techniques for
configuration data:
1. In the *.pl|cgi instance script.
2. In a Perl module.
(For the purpose of discussion, let's assume configuration refers to
key = value pairs, consisting of scalar values. After all, that's what
is stored in an *.ini file.)
The two techniques above are the ones I use most often. I generally
avoid *.ini type files as they are just another asset which has to be
managed. They're marginally easier to edit than Perl, but way too hard
to manage for most non-techie users without a GUI interface.
I have used databases to store this information on occasion, however.
There are some tremendous advantages to doing so. Primarily, once it's
in a database the task of managing run-time settings can be pushed out
to a user-friendly application. The database handles all the issues of
distribution, access and concurrency.
Here's a MySQL-style table DDL:
CREATE TABLE SiteSettings (
setting_name varchar(64) NOT NULL default '',
setting_value_int int(11) default NULL,
setting_value_char varchar(255) default NULL,
PRIMARY KEY (setting_name)
)
All you have to do now is assign particular Keys to various system
settings. For example:
INSERT INTO SiteSettings (setting_name, setting_value_char)
VALUES ('SMTP_SERVER', 'mail.erlbaum.net');
...Or...
INSERT INTO SiteSettings (setting_name, setting_value_int)
VALUES ('ADMIN_USER_ID', 23);
This system now allows you to use some RDBMS cleverness to smooth your
application code. For example, imagine you wanted to get the email
address of the Admin User:
SELECT
email_address
FROM
SiteSettings LEFT JOIN Users
ON SiteSettings.setting_value_int = Users.user_id
WHERE
SiteSettings.setting_name = 'ADMIN_USER_ID';
If you were using an INI file you would have to first read the data
from that source and then select from the database. This way you can
perform the same task in a single operation.
And CGI::Application is one of approved Application Frameworks.
I feel so Validated! Heh...
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Global configuration
Hi Brett -- (For the purpose of discussion, let's assume configuration refers to key = value pairs, consisting of scalar values. After all, that's what is stored in an *.ini file.) Which is why I always had problems with config::Ini -- What if you want to store multiple values to the same key? Use XML? Have a related database table? There are so many different methods of storing configuration data. My inclination is to use less, not more. I consider it a victory if I can eliminate one of the moving parts -- a separate layer, interface, or data store -- in any of my systems. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Beginner question on parameter integrity
Hi Markus -- I would like to know if there are any recommendations for Modules regarding the integrity of parameters i.e. to make shure the user has not tried to tamper with the query string. I stumbled across CGI::EncryptForm, but I don't know if it really integrates smoothly with C::A, or if there are other maybe better solutions. I'm sure that there are some modules which promise to do this, but I've not used any. One tried-and-true technique is to send two versions of each variable -- the first one as clear-text, and the second one encrypted via a one-way mechanism, such as MD5, to act as a checksum. The MD5'd version would use a secret key which would be added before encryption. The key would be stored in your Perl module code ensuring that the user doesn't know it. When you receive back a variable which has been secured via this mechanism you would then re-encrypt the clear-text version you receive and compare it to the encrypted checksum which you have also received. If they match, then you can be reasonably sure that the data has not been tampered. OTOH, it may serve you well to figure out if this is really something you need to do. If all you're doing is securing data which was provided by the user in the first place it may not really serve any purpose to ensure that the user hasn't changed their mind. Most of the time my interest is only in verifying that data I get is not out of bounds. For instance, if the user has a choice from an HTML drop-down I might want to check on the server side to validate that the form data I'm getting is one of the valid enumerated values. For that type of checking there is a module which seems to be popular on this list, and is maintained by a member: Data::FormValidator. I think it's worth taking a look at. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
