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 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)
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)
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)
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)
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)
* 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 pgpW8iKrbFuzC.pgp Description: PGP signature
