Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
At 12:53 PM +1000 4/15/07, Jacinta Richardson wrote: Juerd wrote: Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? Yes, this needs to be redesigned completely. Are you volunteering? Is this still needed? If so yes, I'm now volunteering! Where'd you like me to start? All the best, Jacinta Pursuant to Juerd Waalboer's contributions to the relevant perl6-users discussion threads on 20060917,21, a replacement effort has been started. See the ext/HTTP/ and ext/Web/ skeleton code in the current Pugs repository, which is basically a copy of Juerd's code in the discussion emails, which I wrapped with distributions on his behalf on 20070217. Presumably Juerd will get back to these when he has the tuits, but meanwhile you could try improving what he started. -- Darren Duncan
Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
Darren Duncan skribis 2007-04-14 23:37 (-0700): Presumably Juerd will get back to these when he has the tuits, but meanwhile you could try improving what he started. Indeed. Please read these two posts to this list: http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=stq=juerd+web+developmentrnum=1#a209deddfadad19b http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/2e67c41cf3bd5e35/5db1c4513fb847ff?lnk=stq=juerd+web+developmentrnum=2#5db1c4513fb847ff They outline my thoughts; you'll probably be able to extrapolate most of the interface from it. Whenever you have specific questions, or get stuck, don't hesitate to ask. I can probably find a tuit or two to help, or someone else might. Thanks, -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
At 10:23 AM +0200 4/15/07, Juerd Waalboer wrote: Please read these two posts to this list: http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=stq=juerd+web+developmentrnum=1#a209deddfadad19b http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/2e67c41cf3bd5e35/5db1c4513fb847ff?lnk=stq=juerd+web+developmentrnum=2#5db1c4513fb847ff They outline my thoughts; you'll probably be able to extrapolate most of the interface from it. I should also point out that copies those 2 list posts are also in the Pugs repository, in the docs/ folder of ext/HTTP/ (the more central of the 2 derived projects); I put them there at the same time as creating ext/HTTP/ for purposes of both explanation and posterity; the implementation and rationale are together. Eg, see: http://svn.pugscode.org/pugs/ext/HTTP/docs/ The main advantage to seeing the perl6-users archive versions is that list replies from other people can also be seen there. -- Darren Duncan
Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
Hi, Jacinta Richardson wrote: Juerd wrote: [CGI.pm et al] Yes, this needs to be redesigned completely. Are you volunteering? Is this still needed? If so yes, I'm now volunteering! Where'd you like me to start? I'd like to point out that this might be a good idea for a perl6 microgrant: http://use.perl.org/article.pl?sid=07/03/22/1542235 Afaict so far only 2 out of 10 are granted, so ideas and applications are welcome. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ - http://sudokugarden.de/ - http://perl-6.de/ signature.asc Description: OpenPGP digital signature
CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
Juerd wrote: Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? Yes, this needs to be redesigned completely. Are you volunteering? Is this still needed? If so yes, I'm now volunteering! Where'd you like me to start? All the best, Jacinta
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Randal L. Schwartz wrote: A == A Pagaltzis [EMAIL PROTECTED] writes: A * Randal L. Schwartz merlyn@stonehenge.com [2006-09-20 19:30]: Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes: yet I never needed those HTML generating methods. You've never made a sticky form then. A False dilemma. You can create sticky forms conveniently without A using CGI.pm’s HTML generation stuff. You can use HTML::Template, A HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on? A C’mon merlyn, you’ve been around long enough to know about CPAN A and realise that your statement is transparently fallacious. However, HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not* in core. CGI.pm was. One stop shopping. Easy to describe to people. We need the same thing for Perl6: If you're going to do simple web stuff, please use MUMBLE module. And MUMBLE better have tight integration of param processing and sticky form generation, as well as good header generation for cookies and redirects. In other words, at least two thirds of what CGI.pm does for me now. And MUMBLE better be included *with* Perl6. Without that, people will *hand code* that stuff, and get it wrong, and we'll get the reputation of Perl6 being horrible for the web. I am in favour of different bundles. Then you can, for example yum install perl6-base or yum install perl6-web or yum install perl6-everything You know what I mean. The diff between perl6-base and perl6-web is a bunch of (CPAN6) modules. - Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Aankhen skribis 2006-09-20 18:32 (-0700): If those are modules to generate markup, I don't see why they should under the Web namespace. There needs to be a Web.pm toolkit (or something similar), but that's mostly an amalgamation of other modules. Because they speak the same language. That is: they know about arguments passed via forms, and the preferred output language (xhtml? html?). use Web :typexhtml :html $web; ...; print img(...); # img .../ I'm dreaming that :typexhtml does the following things: 1. Set the MIME-type to application/xhtml+xml 2. Set the output encoding to UTF-8 again, because application/* implied raw 3. Make begin_html (or whatever it'll be called) smart enough to output the correct XML header doctype too 4. Make all html generation methods (requested with :html in my example. Should perhaps be renamed to :htmlgen?) output XHTML compatible tags. If Web::HTML (Web::HTMLgen) is a role to Web, all this can come naturally. If it's a module somewhere else, it's not so obvious that it'll play nicely with the rest. Putting it in the Web namespace, and making it use information from the Web object (which mostly delegates to its .request and .response), doesn't have to mean it can't be used stand-alone. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Randal L. Schwartz wrote: Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes: Fagyal As a side note I also have to add that I really dislike the Fagyal html-functions CGI.pm currently has. Creating the representation is Fagyal the task of the designer, not the programmer. It's almost like echo Fagyal in PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP, Fagyal mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those Fagyal HTML generating methods. To me, imhoit feels wrong that they are Fagyal there/imho. You've never made a sticky form then. Erm... what makes you think so? Not with CGI.pm, but I use HTML::FillInForm for the basic cases (which is simply a per-page config parameter in my framework, and which has the advantage of using simple HTML markup without any coding), and my own module (PET::Filter::UtilXmlMap) for more comples cases when forms are pre-populated from DB. E.g.: ehtml:bodySelect array=subst.pages name=page selected=QUERY.page / (Note: this generates [% Util.ehtml.bodySelect('array', subst.pages, 'name', 'page', selected, QUERY.page %] at compile time.) I think JSP tag libraries had a too strong effect on me :) - Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On 9/21/06, Juerd [EMAIL PROTECTED] wrote: Because they speak the same language. That is: they know about arguments passed via forms, and the preferred output language (xhtml? html?). Ah, I didn't think of that. My bad. Roles for all these things sound great to me. :-) Aankhen
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
A == A Pagaltzis [EMAIL PROTECTED] writes: A * Randal L. Schwartz merlyn@stonehenge.com [2006-09-20 19:30]: Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes: yet I never needed those HTML generating methods. You've never made a sticky form then. A False dilemma. You can create sticky forms conveniently without A using CGI.pm’s HTML generation stuff. You can use HTML::Template, A HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on? A C’mon merlyn, you’ve been around long enough to know about CPAN A and realise that your statement is transparently fallacious. However, HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not* in core. CGI.pm was. One stop shopping. Easy to describe to people. We need the same thing for Perl6: If you're going to do simple web stuff, please use MUMBLE module. And MUMBLE better have tight integration of param processing and sticky form generation, as well as good header generation for cookies and redirects. In other words, at least two thirds of what CGI.pm does for me now. And MUMBLE better be included *with* Perl6. Without that, people will *hand code* that stuff, and get it wrong, and we'll get the reputation of Perl6 being horrible for the web. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Randal L. Schwartz skribis 2006-09-21 9:15 (-0700): We need the same thing for Perl6: If you're going to do simple web stuff, please use MUMBLE module. And MUMBLE better have tight integration of param processing and sticky form generation, as well as good header generation for cookies and redirects. In other words, at least two thirds of what CGI.pm does for me now. And MUMBLE better be included *with* Perl6. To a certain extent, I agree. What do you think of the Web MUMBLE that I proposed? I think I've expressed it in enough detail now, for you to form an opinion. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Randal L. Schwartz wrote: And MUMBLE better be included *with* Perl6. I disagree. Anything that can be left out of the base Perl6 distro should be. * It's too inflexible, so it doesn't allow for a new improved module to come along to replace it. * It requires more from the Perl6 maintainers. * It's impossible for everyone to agree on what should be core because everyone uses Perl6 for different applications. * It's unnecessary bloat. But this has all been discussed before... Randy.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
* Randal L. Schwartz merlyn@stonehenge.com [2006-09-22 01:25]: HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not* in core. CGI.pm was. One stop shopping. Easy to describe to people. That still doesn’t prove that tight coupling is necessary between parameter parsing and HTML generation. The concept of core is getting a do-over for Perl 6 anyway. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
It sounds like the name of HTTP is more appropriate: HTTP::Request ...uri, pathinfo, params, method, headers, etc. HTTP::Request::Session ...adds to HTTP::Request to provide session() method HTTP::Response ...response code, content, headers, etc. HTTP::Response::JSON ...extends response.write() to encode JSON Maybe CGI.pm could adapt these to the CGI environment and ecapsulate their functionality. Maybe it's too servlety. On 9/17/06, Juerd [EMAIL PROTECTED] wrote: Mark Stosberg skribis 2006-09-16 22:04 (-0500): As far as I'm aware, no work on CGI::Session for Perl 6 has started yet. I'm happy about that, because this module must not have CGI in its name. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] -- Ian Langworth
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Ian Langworth skribis 2006-09-19 19:02 (-0700): It sounds like the name of HTTP is more appropriate: HTTP::Request ...uri, pathinfo, params, method, headers, etc. (etc) Well, yes and no. HTTP is today's web protocol standard, but may not be with us forever. I was thinking of getting these HTTP modules from LWP (and Perl6-ify them, and change some method names), and then letting Web::Blah inherit from HTTP::Blah as a first implementation. Maybe CGI.pm could adapt these to the CGI environment and ecapsulate their functionality. Maybe I think that that should absolutely not belong in a root namespace. Though yes, CGI.pm could be in a directory, like Web/CGI.pm :) Maybe it's too servlety. No, it's perfect, if we change just a few things (mostly the number of convenience methods that are just delegations, and introduce some real convenience instead.) -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Ian Langworth wrote: It sounds like the name of HTTP is more appropriate: HTTP::Request ...uri, pathinfo, params, method, headers, etc. HTTP::Request::Session ...adds to HTTP::Request to provide session() method HTTP::Response ...response code, content, headers, etc. HTTP::Response::JSON ...extends response.write() to encode JSON Maybe CGI.pm could adapt these to the CGI environment and ecapsulate their functionality. Maybe it's too servlety. It is :) It is probably the *proper* way, but definetely not the *efficient* way. You rarely do real HTTP handling when you use CGI. A general, simple CGI handling module fits into 200 lines, including POD. Imagine like sub parseQueryStupidAndWrong { my $self = shift; $ENV{'QUERY_STRING'} || return {}; my @pairs = split(//, $ENV{'QUERY_STRING'}); my %query; foreach my $pair (@pairs) { my ($key, $value) = split (/=/, $pair); $key =~ tr/+/ /; $key = whatever::url_decode($key); $value =~ tr/+/ /; $value = whatever::url_decode($value); if ($query{$key}) { $query{$key} .= , $value; } else { $query{$key} = $value; } } return \%query; } You don't really need more. IMHO a CGI module parses/preprocesses/decodes/etc. all incoming parameters (POST, GET, COOKIES), and that's it. It might give some useful other routines (e.g. url encoding / decoding, various ways to mix GET+POST, set content types more easily, etc.), but other than that, it should be very lightweight and easy to use. - Cs.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor schrieb: Ian Langworth wrote: A general, simple CGI handling module fits into 200 lines, including POD. [..] You don't really need more. IMHO a CGI module parses/preprocesses/decodes/etc. all incoming parameters (POST, GET, COOKIES), and that's it. I can support this statement: In a ~30k lines (incl POD) web project I actually use CGI.pm mostly for parameter parsing: $ grep -ri 'cgi-' * | grep -v new | wc -l 97 Wehereas I hardly use for anything else: $ grep -ri 'cgi-' * | grep -v new | grep -v param | wc -l 7 4 of these 7 matches address file upload handling, the other 3 match in an other custom module with the name *::CGI - not CGI.pm. But I think that it would be a good idea to create a clean, servlety foundation, upon which you still can implement a 200 lines CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks. Regards -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor skribis 2006-09-20 11:28 (+0200): You rarely do real HTTP handling when you use CGI. You may not, but many people do a lot of these things. And when you don't, the datastructures are currently parsed and filled anyway, so I don't know why you say it'd be too inefficient. A general, simple CGI handling module fits into 200 lines, including POD. Imagine like That's not CGI handling, that's form parameter parsing. CGI, and web programming, is much more than that. You don't really need more. I think you mean: I don't really need more. Many people do need a whole lot more, and CGI.pm does do a whole lot more. Just not in a nicely organized set of classes. It's unfortunate that it mostly lets the user handle headers that are communicated through ENV, precisely because that's part of the CGI spec, and not common to other kinds of web programming, so it's specifically a job for a module called CGI.pm It might give some useful other routines (e.g. url encoding / decoding, various ways to mix GET+POST, set content types more easily, etc.), but other than that, it should be very lightweight and easy to use. I agree that things should be lightweight and easy to use. But in Perl 6, that doesn't mean that you should avoid nicely structured OO. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Thomas Wittek wrote: [...] But I think that it would be a good idea to create a clean, servlety foundation, upon which you still can implement a 200 lines CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks. That sounds nice. - Cs.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Juerd wrote: Fagyal Csongor skribis 2006-09-20 11:28 (+0200): You rarely do real HTTP handling when you use CGI. You may not, but many people do a lot of these things. Actually me, too. Not with CGI.pm, though. I tend to use CGI::Simple for form/param parsing, Template.pm for template processing, LWP::Simple for... well, HTTP handling (kind of...) and so on and so on. And when you don't, the datastructures are currently parsed and filled anyway, so I don't know why you say it'd be too inefficient. Inefficient was probably a bad choice of word. I would rather say: I would not like to see Perl6's CGI.pm as a monster module, which has one part everyone uses, and one hundred other parts that some uses, because I feel those parts should be put into other modules. I just feel quilty when I use (Perl5's) CGI.pm for such trivial tasks as parameter parsing. Feels like... say, using MIME::Lite for *sending* mail not *constructing*. Or maybe... you know, I have a Windows XP installed at home. The one thing I use it for is to run dvdsrhink :)) That's a big price for 10G of discspace :) As a side note I also have to add that I really dislike the html-functions CGI.pm currently has. Creating the representation is the task of the designer, not the programmer. It's almost like echo in PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP, mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those HTML generating methods. To me, imhoit feels wrong that they are there/imho. A general, simple CGI handling module fits into 200 lines, including POD. Imagine like That's not CGI handling, that's form parameter parsing. CGI, and web programming, is much more than that. That I know :) That's what I do for a living :), for almost like 10 years now. And I started with cgi-lib.pl :) ...which makes me think CGI.pm should not do much more than that old horse. But please see below. You don't really need more. I think you mean: I don't really need more. Many people do need a whole lot more, and CGI.pm does do a whole lot more. My public domain framework's dispatcher class starts something like: use strict; use FCGI; use Template; use Template::Stash; use CGI::Simple::Cookie; use CGI::Simple; use Config::General; use Data::Dumper; use Time::HiRes; use Digest::MD5; use PET::GCONF; use HTML::FillInForm; use LWP::Simple; use MIME::Base64 qw/encode_base64/; use PET::Filter; use PET::Util; use PET::Log; use PET::CacheControl; use Storable; use Carp qw/croak cluck carp/; use UNIVERSAL; use BSD::Itimer; use POSIX qw/setuid setgid/; use BSD::Resource; And that's just the dispatcher - the framework uses every third module from CPAN, so to say :) So I am also between those people who need a lot more - yet I think CGI.pm should only do parameter parsing. But no, that is not correct. What I really want to say is that I have no problem with any parts of the original CGI.pm, *except for* the HTML generation stuff. CGI/Lite.pm is ~1200 lines. CGI.pm is ~7500 lines. And what is missing? From the man page of CGI::Simple: CGI::Simple provides a relatively lightweight drop in replacement for CGI.pm. It shares an identical OO interface to CGI.pm for parameter parsing, file upload, cookie handling and header generation. This mod- ule is entirely object oriented, however a complete functional interface is available by using the CGI::Simple::Standard module. Essentially everything in CGI.pm that relates to the CGI (not HTML) side of things is available. There are even a few new methods and additions to old ones! If you are interested in what has gone on under the hood see the Compatibility with CGI.pm section at the end. Just not in a nicely organized set of classes. If you put it that way, I can certanly agree. It's unfortunate that it mostly lets the user handle headers that are communicated through ENV, precisely because that's part of the CGI spec, and not common to other kinds of web programming, so it's specifically a job for a module called CGI.pm It might give some useful other routines (e.g. url encoding / decoding, various ways to mix GET+POST, set content types more easily, etc.), but other than that, it should be very lightweight and easy to use. I agree that things should be lightweight and easy to use. But in Perl 6, that doesn't mean that you should avoid nicely structured OO. If we talk about nicely structured OO, I can see a few ways: - CGI.pm include something like CGI::HTML, to get rid of the HTML generating part, or maybe even separating CGI::HTML and CGI::Request - now that I write it down, for me it feels more natural to have something like HTML::CGI : # imagine something like: $cgi = new CGI; $html = HTML::CGI-new($cgi); $html-popup_menu( ... ); # I won't do this, but others might... :) ...and still I think that a module named CGI should handle the CGI 1.1
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Erm... Sorry for the bandwith usage again, but what about something like class CGI is CGI::Base does CGI::ParamParser does CGI::HTML { ... } ? To make CGI.pm kind of backward compatible, but separates the layers. (Please excuse my bad syntax/semantics.) - Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor wrote: # imagine something like: $cgi = new CGI; $html = HTML::CGI-new($cgi); $html-popup_menu( ... ); # I won't do this, but others might... :) My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? I'd love the Perl 6 version to have a compatibility mode where it returned the methods we're all used to, but encouraged something which was more intuitive. Perhaps that would be better in two modules which essentially did the same thing though. All the best, J
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor skribis 2006-09-20 15:43 (+0200): Inefficient was probably a bad choice of word. I would rather say: I would not like to see Perl6's CGI.pm as a monster module, which has one part everyone uses, and one hundred other parts that some uses, because I feel those parts should be put into other modules. Perl 6's Web toolkit, even with all these classes, is likely to be much lighter than Perl 5's CGI.pm with :standard. But note that especially if it is a well designed bundle of classes/roles, you can pick exactly those things that you need, and leave all others out. That's part of the reason why you should separate things. As a side note I also have to add that I really dislike the html-functions CGI.pm currently has. Creating the representation is the task of the designer, not the programmer. That's an ideal world. Many programmers have to hack some HTML themselves. I do think that they're far better off with raw HTML, but there are people who prefer the generation methods, and we should try to make everyone happy, not just ourselves. To me, imhoit feels wrong that they are there/imho. It *is* wrong to have them in CGI.pm. It wouldn't be wrong to have them in a Web toolkit. In any case, I think they should only be loaded on request. And that's just the dispatcher - the framework uses every third module from CPAN, so to say :) So I am also between those people who need a lot more - yet I think CGI.pm should only do parameter parsing. I think CGI.pm, as in Perl 5, should not ever be written for Perl 6. I think Web::CGI could handle CGI requests well, but not just parameter parsing. It should also do ENV parsing. If you want to implement only parameter parsing, don't ask for CGI, because CGI is more than that. generation stuff. CGI/Lite.pm is ~1200 lines. CGI.pm is ~7500 lines. And Please don't measure things in lines. For starters, your line counts include documentation. These numbers are meaningless. If we talk about nicely structured OO, I can see a few ways: - CGI.pm include something like CGI::HTML, to get rid of the HTML generating part, or maybe even separating CGI::HTML and CGI::Request s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except perhaps for its compatibility syntax), and neither does HTTP::Daemon. We should write generic code, suitable for any implementation. I'm thinking of: Web::Init::CGI # Initializer for CGI requests Web::Init::FastCGI # Initializer for FastCGI requests Web::Init::ModPerl # Initializer for ModPerl requests Web::Request# Request objects Web::Response # Response objects Web::Session# Session objects Web::HTML # HTML generation Web::Util # HTML-entities, URI-encoding, etc Web # utility module that mostly loads other modules - now that I write it down, for me it feels more natural to have something like HTML::CGI : # imagine something like: $cgi = new CGI; $html = HTML::CGI-new($cgi); $html-popup_menu( ... ); # I won't do this, but others might... :) use Web $web :html; $web.popup_menu(...); implemented by something like class Web { has $.request; ... } role Web::HTML { method popup_menu(...) { # something with .request } } ...and still I think that a module named CGI should handle the CGI 1.1 (1.2) specification (read *STDIN, write to *STDOUT, parse %ENV , that is) and do nothing more. That's a good idea, and I agree. But CGI.pm should only be a tiny part of our web toolkit. You know... as the matter of fact, I think we are only arguing about namespace usage here :)) Yes. I'm talking about a web development toolkit, that does at least what CGI.pm did, and not about CGI as a namespace, because I think that's an incredibly bad thing anyway. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? Yes, this needs to be redesigned completely. Are you volunteering? I'd love the Perl 6 version to have a compatibility mode where it returned the methods we're all used to, but encouraged something which was more intuitive. Perhaps that would be better in two modules which essentially did the same thing though. The compatibility mode is perl5:CGI, that loads the old Perl 5 CGI.pm. There's little need for us to port bad things to Perl 6. Peoplo who really want or need to use them can, and we should concentrate on creating something that's GOOD for new code. This said, I do think it'd be wise to document changes in accessible tables. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Juerd wrote: [...] Fagyal Csongor skribis 2006-09-20 15:43 (+0200): Inefficient was probably a bad choice of word. I would rather say: I would not like to see Perl6's CGI.pm as a monster module, which has one part everyone uses, and one hundred other parts that some uses, because I feel those parts should be put into other modules. Perl 6's Web toolkit, even with all these classes, is likely to be much lighter than Perl 5's CGI.pm with :standard. I guess that's one of the reasons we are heading from 5 to 6 :) But note that especially if it is a well designed bundle of classes/roles, you can pick exactly those things that you need, and leave all others out. That's part of the reason why you should separate things. And here is another reason :) [...] If we talk about nicely structured OO, I can see a few ways: - CGI.pm include something like CGI::HTML, to get rid of the HTML generating part, or maybe even separating CGI::HTML and CGI::Request s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except perhaps for its compatibility syntax), and neither does HTTP::Daemon. We should write generic code, suitable for any implementation. I'm thinking of: Web::Init::CGI # Initializer for CGI requests Web::Init::FastCGI # Initializer for FastCGI requests Web::Init::ModPerl # Initializer for ModPerl requests Web::Request# Request objects Web::Response # Response objects Web::Session# Session objects Web::HTML # HTML generation Web::Util # HTML-entities, URI-encoding, etc Web # utility module that mostly loads other modules Hmmm. A very sound idea. Reorganising the CPAN namespace :) (This CGI/HTTP/LWP/HTML/etc. got a bit confusing as it grew.) I would say, maybe add Web::Tools::* so that others can add various useful (and not that useful) modules without mixing up everything. And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. So is Web::Init::* class supposed to be selected by Web, and Web::Init(::*) used by e.g. Web::Request Web::Response, so it all becomes transparent? Yes. I'm talking about a web development toolkit, that does at least what CGI.pm did, and not about CGI as a namespace, because I think that's an incredibly bad thing anyway. I absolutely agree. - Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes: Fagyal As a side note I also have to add that I really dislike the Fagyal html-functions CGI.pm currently has. Creating the representation is Fagyal the task of the designer, not the programmer. It's almost like echo Fagyal in PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP, Fagyal mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those Fagyal HTML generating methods. To me, imhoit feels wrong that they are Fagyal there/imho. You've never made a sticky form then. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
* Randal L. Schwartz merlyn@stonehenge.com [2006-09-20 19:30]: Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes: yet I never needed those HTML generating methods. You've never made a sticky form then. False dilemma. You can create sticky forms conveniently without using CGI.pm’s HTML generation stuff. You can use HTML::Template, HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on? C’mon merlyn, you’ve been around long enough to know about CPAN and realise that your statement is transparently fallacious. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On 9/20/06, Fagyal Csongor [EMAIL PROTECTED] wrote: And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. If those are modules to generate markup, I don't see why they should under the Web namespace. There needs to be a Web.pm toolkit (or something similar), but that's mostly an amalgamation of other modules. Aankhen
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
I agree completely. In that vein, I think that one thing a lot of web developers would like to have available more easily would be session management. In PHP it's as simple as $_SESSION['key'] = 'value'. I understand that CGI.pm is a fundemantally different concept from PHP and that this can't be completely taken care of by the module. Still, if something could be written in, I think it would make many people's lives simpler. In Perl 5, CGI::Session is one solution that feels this gap well. In frameworks like CGI::Application, sessions can be integrated so they are apart of the of the same object anyway: self.query -- CGI.pm object self.session -- CGI::Session object. As far as I'm aware, no work on CGI::Session for Perl 6 has started yet. I'm sure there will be some things that would be nice to change about it as well, as it currently has some features only for backwards compatibility. Mark
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Mark Stosberg skribis 2006-09-16 22:04 (-0500): As far as I'm aware, no work on CGI::Session for Perl 6 has started yet. I'm happy about that, because this module must not have CGI in its name. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
* Yuval Kogman [EMAIL PROTECTED] [2006-09-12 12:05]: There are *so* many ways to do session handling that lugging them all into CGI.pm will just make a mess. Agreed, but maybe this is a case where it would make sense to do something like what Perl 6 does for OO vs Perl 5, ie provide one good default set of options that people can use without thinking too much about it when they first get started? F.ex., I could imagine that CGI.pm6 would provide a framework for plugging in session implementations somehow (insert your wisdom from the Catalyst design here f.ex.), and then comes with an easy to set up default session store that would be configured in the course of Perl 6 installation. This way, it would work the way PHP works: when the sysadmin installs it, it is automatically fully set up to provide sessions somehow, and only the people who really need performance or special features need to think harder about it. (Which they can, because the whole thing is still pluggable.) I think we stand to gain a lot from adopting the PHP/Python “batteries included” attitude (cf. Elaine’s Law). (I note that Catalyst is not holding up so well there… although it has made great strides, in all fairness.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
F.ex., I could imagine that CGI.pm6 would provide a framework for Please, please, please, let us not call this module CGI or anything closely resembling it. This will only fool a lot of inexperienced Perl 5 programmers, and start a lot of fuss about the interface being incompatible. And, of course, the name CGI is just totally *WRONG*, for several reasons, *especially* if we provide Session support built in. This way, it would work the way PHP works: when the sysadmin installs it, it is automatically fully set up to provide sessions somehow, and only the people who really need performance or special features need to think harder about it. (Which they can, because the whole thing is still pluggable.) Agreed. We can safely default to file based sessions, like PHP does. This is one of the things that PHP got right! Inefficiency, cruft accumulating in /tmp, and the possible inavailability of a tmp directory is not our problem. That's a sysadmin thing. We can easily make this work out of the box for 95%[1] of all installations. [1] Like 53.4% of all statistics, this one is made up and based only on 0.5% actual research that nobody can actually recall, and based precisely 88.445% on the writer's own experience. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On Mon, Sep 11, 2006 at 13:31:55 -0700, Michael Snoyman wrote: I agree completely. In that vein, I think that one thing a lot of web developers would like to have available more easily would be session management. In PHP it's as simple as $_SESSION['key'] = 'value'. I understand that CGI.pm is a fundemantally different concept from PHP and that this can't be completely taken care of by the module. Still, if something could be written in, I think it would make many people's lives simpler. Please... no... There are *so* many ways to do session handling that lugging them all into CGI.pm will just make a mess. It'd work much better as mixin plugins of some sort. I'd be happy to discuss my conclusions from redesigning the Catalyst session handling, if you like. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpVLxZTi14RK.pgp Description: PGP signature
CGI Session management (was Re: the CGI.pm in Perl 6)
If Perl6 CGI.pm is intended to be the successor of the P5 CGI.pm (the quasi-standard for Perl web programming) is should really get a modern design. I agree completely. In that vein, I think that one thing a lot of web developers would like to have available more easily would be session management. In PHP it's as simple as $_SESSION['key'] = 'value'. I understand that CGI.pm is a fundemantally different concept from PHP and that this can't be completely taken care of by the module. Still, if something could be written in, I think it would make many people's lives simpler. Perhaps a method like CGI-get_session_key, which would return a unique ID and handle all this via cookies without the developer needing to notice anything. It would then be a lot easier to keep a (flat file|dbm|sql database) of information tied to that ID. On the other hand, that might be the kind of feature that needs to be done in a seperate module. In any case, I'd be happy to help out with writing it; I'm just not entirely certain of how it should work. Michael