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: the CGI.pm in Perl 6
Larry Wall skribis 2006-09-20 16:34 (-0700):
That should work but my preference is just
my @bar = $q.parambar[];
That is, empty .[] has the same arrayifying semantics as @. (This is
currently b0rken in pugs though.) Likewise .{} is equivalen to %.
Nice, but what's the syntax for an empty slice then?
--
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)
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: the CGI.pm in Perl 6
* Juerd [EMAIL PROTECTED] [2006-09-20 22:25]:
I think it's time we moved away from the param method, and
started using a hash.
I don’t know about that. The `param` method has the nice property
that it allows you to pretend everything’s a single value or to
use multi-valued params, at your own discretion, at any time,
with no change of syntax.
my $foo = $q-param( 'foo' );
my @bar = $q-param( 'bar' );
If you tried to do this with a hash, you’d get
my $foo = $q-param-{ 'foo' }[0];
# my ( $foo ) = @{ $q-param-{ 'foo' } };
my @bar = @{ $q-param-{ 'bar' } };
You could try making the type of the value depend on arity and be
either a scalar or an arrayref, but then you get V*E*R*Y U*G*L*Y
client code that needs to constantly check whether it’s dealing
with one or the other.
Does Perl 6 offer any help in making access to a HoL look like
the first example? If not, then no, let’s please stick with the
`param` protocol.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
On Thu, Sep 21, 2006 at 12:43:41AM +0200, Juerd wrote:
: my @bar = @{ $q-param-{ 'bar' } };
:
: my @bar = $q.parambar.'@';
: my @bar = @ $q.parambar;
That should work but my preference is just
my @bar = $q.parambar[];
That is, empty .[] has the same arrayifying semantics as @. (This is
currently b0rken in pugs though.) Likewise .{} is equivalen to %.
Larry
Re: the CGI.pm in Perl 6
David == David Cantrell [EMAIL PROTECTED] writes: But don't throw out the simplicity of CGI.pm's basic task handling: parsing the incoming parameters (including file upload), and generating sticky forms and other common HTML elements. David That's two tasks. It should be two modules. No, it's an *integrated* task. The form-generation stuff needs tight coupling with the getting (and setting) of the incoming param values. You couldn't just use two random modules for that... they'd have to specifically know about each other and work together. That's why it's great that it's all in CGI.pm. If I just want param handling, I import/compile only that part. If I also want sticky forms, I just ask it for a bit more. And as long as I'm there, I import header or redirect or cookie to do that last bit of my application. CGI.pm has the *right* mix for small tasks. It *does* make sense. -- 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: the CGI.pm in Perl 6
(Randal L. Schwartz) schrieb:
David == David Cantrell [EMAIL PROTECTED] writes:
David That's two tasks. It should be two modules.
No, it's an *integrated* task. The form-generation stuff needs tight
coupling
with the getting (and setting) of the incoming param values.
A separate module, say HTML::Formgenerator, could easily use CGI.pm (or
Web.pm,...) to get and set parameters:
$value = $query-param('foo');
$query-param('foo','an','array','of','values');
I see no need to integrate those modules.
Regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: the CGI.pm in Perl 6
Randal L. Schwartz wrote: David == David Cantrell [EMAIL PROTECTED] writes: But don't throw out the simplicity of CGI.pm's basic task handling: parsing the incoming parameters (including file upload), and generating sticky forms and other common HTML elements. David That's two tasks. It should be two modules. No, it's an *integrated* task. The form-generation stuff needs tight coupling with the getting (and setting) of the incoming param values. You couldn't just use two random modules for that... they'd have to specifically know about each other and work together. That's why it's great that it's all in CGI.pm. If I just want param handling, I import/compile only that part. If I also want sticky forms, I just ask it for a bit more. And as long as I'm there, I import header or redirect or cookie to do that last bit of my application. CGI.pm has the *right* mix for small tasks. It *does* make sense. To be honest I'm not sure I follow your argument. Why does populating a form from incoming form data require closer integration than, say, pulling it out of a database and populating a form for further editing?. Surely its just a question of a consistant interface? Forgive me if I have misunderstood your point. Steve
Re: the CGI.pm in Perl 6 (create a design on the wiki)
Juerd wrote: It does make sense to have a single toolkit that does all this. It does not make sense to have a single .pm that does all this. There's absolutely no need for having all these different tasks in one module. There's not even any benefit. You can just as well use a couple of nicely named, grouped, and reasonably standalone roles or classes, and then a single module to combine them all for the ease of use that you like. I suggest that those who have concrete ideas sketch out the API through a new page on the wiki. That could make it easier for someone else to pick up, if they have programming skill, but less API design experience. The result might be even multiple API designs (A more compatible CGI.pm and cleaner/newer/different Web.pm solution). http://rakudo.org/perl6/index.cgi Mark
Re: the CGI.pm in Perl 6
* Randal L. Schwartz merlyn@stonehenge.com [2006-09-19 21:25]: The form-generation stuff needs tight coupling with the getting (and setting) of the incoming param values. You couldn't just use two random modules for that... they'd have to specifically know about each other and work together. Err, no. They just need a known protocol, and the semantics of CGI.pm’s `param` method have spread pretty widely and are now used by many other modules as well. In general, you can pass instances from any of these modules to anything that expects something that speaks that protocol and they work just fine. F.ex., you can pass CGI::Simple objects into HTML::Template for variable prepopuluation and it Just Works because they talk to each other using the CGI.pm `param` protocol. Form handling clearly requires no coupling. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
Randal L. Schwartz wrote: The thing that CGI.pm does is put in one place everything you need for a simple web form. And there's an amazing number of applications for this... putting a contact us page on an otherwise static site comes to mind immediately. Sure, if you're building a complex shopping cart application, you're gonna reach for Jifty or Catalyst, or at least roll your own with Template Toolkit or Mason, and you'd be silly to use either CGI.pm's parsing or HTML generation in those cases. You seem to be forgetting the case in the middle - a small dynamic site. IMHO that is: most sites. My weapons of choice for that are CGI.pm to parse requests and Template Toolkit to stuff the relevant content into templates. That's why I use CGI::Lite - no fancy HTML, only a lightweight module with themost important features. (Gee, I am emitting WML sometimes!) And let me add this as a side note: http://www.w3.org/CGI/ IMHO a module should do what its name stands for. Surely, when I do something with CGI, I also do HTML generation in 99% of the time. But as the matter of fact, I also use DBI in 99% of the time, so why not put DBI into CGI.pm, too? ;) [...] But don't throw out the simplicity of CGI.pm's basic task handling: parsing the incoming parameters (including file upload), and generating sticky forms and other common HTML elements. That's two tasks. It should be two modules. Absolutely. I suppose you could argue that generating FORM tags specifically and all their baggage like INPUTs might fall under its remit (they are, after all, what generates the fancy requests that are CGI's bread and butter), but generating H1 tags is most definitely not anything to do with CGI. Also consider that handling the input part of CGI is very straightforward. No matter what system/language you use, you basically do the same thing (parse/access GET/POST, the ENV variables, etc.) On the other hand, handling the output is much more dubious - besides setting the content type on some other headers, there are dozens of ways to handle/mangle the content you output. Perl5's CGI.pm provides a way, but that is IMHO just a legacy API Perl6 has nothing to do with. Basically everyone who use CGI.pm use -param() - but only a few use -h1(), for example. (IMHO if something beyond CGI input handling must go into CGI.pm, then that is cookie handling - but that's another story.) Just my two cents. - Fagzal
use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)
Aankhen wrote: The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). In theory, use perl5:CGI could be a fine solution. In practice, it hasn't worked out well for me. Even something that seems simple like passing a hashref to Perl 5 is not documented now. In summary, I found it easier to update CGI.pm p6 to meet my needs than to 'use perl5:CGI' to meet my needs. I think the reality it is yet to been seen now well calls to Perl 5 modules can work for the general case. Mark
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
best practice for web form stickiness (was: Re: the CGI.pm in Perl 6)
Juerd wrote: Personally, I am *against* HTML generating for elements that are not form fields. And for form fields, I think the solution should be in the templating thing, not elsewhere. Stickiness makes sense on invalid data only anyway, and we need to put the error message and a pointer somewhere, and those are also templating things. Even the simple contact page is much better off with a nice templating tool, than with HTML generating methods. I think HTML::FillInForm is a much better way to handle form stickiness. It allows you to keep the form generation in HTML /and/ still support stickiness. So, it's fine with me if the sticky feature of CGI.pm doesn't re-appear. Mark
use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)
Aankhen wrote: The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). In theory, use perl5:CGI could be a fine solution. In practice, it hasn't worked out well for me. Even something that seems simple like passing a hashref to Perl 5 is not documented now. In summary, I found it easier to update CGI.pm p6 to meet my needs than to 'use perl5:CGI' to meet my needs. I think the reality it is yet to been seen now well calls to Perl 5 modules can work for the general case. 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: the CGI.pm in Perl 6
* Trey Harris [EMAIL PROTECTED] [2006-09-10 23:50]: But the HTML methods are used everywhere. And the more novitiate the programmer, the more likely they are to be using them spaghetti-like throughtout their code. If they discover that every time they see a Cstart_form it's going to entail new coding, they're going to rapidly get discouraged about porting to Perl 6. I see that argument. So build a lean, well-designed CGI module, but also offer a CGI5 module that aggregates the CGI stuff along with HTML::Gen and whatnot into a CGI.pm5-compatible API melange for easy porting. No need to drag old mistakes along for all eternity just for the sake of their familiarity. 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: HTTP::Request/Response (was Re: the CGI.pm in Perl 6)
On 9/14/06, Darren Duncan [EMAIL PROTECTED] wrote: Having had some prior experience in tackling this problem (eg, CGI::Portable), I will endeavour to work on / help with the Perl 6 analogy to HTTP::Request/Response, so to replace the use of corresponding aspects of CGI.pm. I really like this idea. I was actually working on a threaded HTTP server in Perl that used that exact approach. The idea was that you could write a HTTP::Server::Threaded::Handler implementation; this could easily work for CGI as well. I can't test my code, since my Pugs installation is currently broken (I've been working on it from work, and I'm trying to get everything working in Cygwin right now). However, I've posted my code at this URL: http://oss.snoyman.com/HTTP-Server-Threaded.tar.gz As a note to Audrey: This is what I was asking about threads for; I added the async statement, but haven't tested it. Michael
Re: the CGI.pm in Perl 6
Randal L. Schwartz skribis 2006-09-15 9:15 (-0700): The thing that CGI.pm does is put in one place everything you need for a simple web form. And there's an amazing number of applications for this... putting a contact us page on an otherwise static site comes to mind immediately. Yes, it's great to have a standard toolkit. It's also totally acceptable that a single thing exports several task related things at once. use Web; my $web = Web::Request.new does HTML::Generator; HTML::Generator can be smart enough to realise that when it's used as a role to extend Web::Request, it can provide stickiness for form elements. In fact, if you want to build a newbie friendly thing, just export a pre-built $web, much like LWP::Simple can export a $ua: use Web::Simple :html :cookies :sessions; But don't throw out the simplicity of CGI.pm's basic task handling: parsing the incoming parameters (including file upload), and generating sticky forms and other common HTML elements. Don't thow out the simplicity, but do severely re-model things! -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: the CGI.pm in Perl 6
Juerd skribis 2006-09-15 23:26 (+0200): Randal L. Schwartz skribis 2006-09-15 9:15 (-0700): The thing that CGI.pm does is put in one place everything you need for a simple web form. And there's an amazing number of applications for this... putting a contact us page on an otherwise static site comes to mind immediately. Yes, it's great to have a standard toolkit. It's also totally acceptable that a single thing exports several task related things at once. Hm, removed two paragraphs that I wanted to keep: But this thing should not be called CGI. It's not CGI-specific. Also, this should not internally put everything on one big pile. We have roles now, and roles make it easy to compose an object of the things that we like, leaving out the things that we don't like. Personally, I am *against* HTML generating for elements that are not form fields. And for form fields, I think the solution should be in the templating thing, not elsewhere. Stickiness makes sense on invalid data only anyway, and we need to put the error message and a pointer somewhere, and those are also templating things. Even the simple contact page is much better off with a nice templating tool, than with HTML generating methods. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
HTTP::Request/Response (was Re: the CGI.pm in Perl 6)
At 5:00 PM -0700 9/14/06, Aankhen wrote: There were a few discussions with Juerd and others in #perl6 about CGI.pm in Perl 6... if anyone's interested, I'll look for the logs. The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). Rather, there needs to be proper seperation of concerns. Maybe instead of just importing CGI, you'd now import HTTP::Request::CGI and HTML::Generator (I'm throwing names out at random, although I did write HTTP::Request::CGI as a subclass of HTTP::Request whose members are populated in a manner similar to CGI.pm's parsing of %ENV). While I wasn't involved in that discussion, I agree with the sentiment you have expressed here, wherein there should be no CGI.pm in Perl 6. (Moreover, we should probably make an effort that no Perl 6 module will have just a top-level namespace as its name unless it is a core module or it is a framework.) Having had some prior experience in tackling this problem (eg, CGI::Portable), I will endeavour to work on / help with the Perl 6 analogy to HTTP::Request/Response, so to replace the use of corresponding aspects of CGI.pm. Note that the design strategy I had used in CGI::Portable was to have a pure container object representing a request and/or response, which was used sort of like this: 1. At start of handling an HTTP request, the main server runloop creates a new Request Container and has it populated by invoking a module function that knows about a particular environment, such as IO::Socket vs mod_perl vs CGI or whatever. 2. The main runloop calls the application's main per-request handling function; that function reads its HTTP input details from Request Container and writes its HTTP output details to Response Container. 3. At end of handling an HTTP request, the main server runloop invokes a module function that knows about a particular environment, and that function outputs whatever the Response Container represents. Note that, in the general case, the Request/Response containers would not have any ties to outside environment, though in specific cases where input and output are too large to easily fit in RAM at once, there can be enhancements. -- Darren Duncan
Re: Web.pm or something (Re: the CGI.pm in Perl 6)
At 5:00 PM +0100 9/13/06, David Cantrell wrote: On Tue, Sep 12, 2006 at 03:08:03PM -0700, Darren Duncan wrote: The word CGI generally speaks to an old, weak, and relatively inefficient technology ... modern proper stuff does not spin off a separate process for each server request; it reuses an existing server ala mod_perl. To me the Commong Gateway Interface means a standard method for dealing with data supplied by the user, nothing more. It certainly doesn't specify how you should implement it. Indeed, every mod_perl application I've seen uses CGI. I beg to differ. CGI is very much an implementation detail. It is a gateway protocol for how 2 different processes communicate. See: http://www.w3.org/CGI/ An HTTP server is often used as a gateway to a legacy information system; for example, an existing body of documents or an existing database application. The Common Gateway Interface is an agreement between HTTP server implementors about how to integrate such gateway scripts and programs. And: http://en.wikipedia.org/wiki/Common_Gateway_Interface The Common Gateway Interface (CGI) is a standard protocol for interfacing external application software with an information server, commonly a web server. This allows the server to pass requests from a client web browser to the external application. The web server can then return the output from the application to the web browser. Because this technology generally requires a fresh copy of the program to be executed for every CGI request, the workload could quickly overwhelm web servers, inspiring more efficient technologies such as mod_perl or ASP that allow script interpreters to be integrated directly into web servers as modules, thus avoiding the overhead of repeatedly loading and initializing language interpreters. So CGI is absolutely not a good name for a new and modern module's design where the module's functionality isn't CGI-specific. -- Darren Duncan
Re: the CGI.pm in Perl 6
Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. But then this new module cannot profit of the popularity of the name CGI.pm and many people will say Ah, Perl6 web development is stuck at the 10 years old Perl5 CGI.pm interface. I'll use (python|ruby( on rails)?|.+). That would be sad. IMHO even Perl people like me will think Ah, Perl6 web development is stuck at the 10 years old Perl5 CGI.pm interface just *because* of the name, regardless of a changed internal api. I would strongly expect the CGI module to do the same as it did for the last 200 years and create another name for any new school web development. Catalyst, Jifty, Acme, Acyou, SillyIdol, WhatEver. The name CGI smells like, erm, yes, C...G...I. If RoR would have sold itself with CGI in its name, it hadn't been that successful. In mankind's history, everything *not* named CGI had a chance to success, even PHP. It will be impossible to resurrect a hype around the word CGI. Because of the word. Not the api. IMHO. Of course. :-) GreetinX Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
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
Re: the CGI.pm in Perl 6
Steffen Schwigon schrieb: Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. I would strongly expect the CGI module to do the same as it did for the last 200 years and create another name for any new school web development. Catalyst, Jifty, Acme, Acyou, SillyIdol, WhatEver. So we might agree ;) Catalysy, Jifty [..] are all higher level complete frameworks. I used CGI.pm for rather lower level tasks (POST/GET-parsing, HTTP redirects, ...) than as a foundation to build complete applications (where the higher level framework come in). So I think that there should be a (well designed) module for those lower level (donkeywork) tasks and only for those (so definitely no HTML-generation...). Other frameworks (or simple CGI-scripts or even a backwards compatible CGI.pm) could be built upon this foundation. -Thomas
Re: the CGI.pm in Perl 6
Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. My 0.02 ₪: CGI.pm will be better off redesigned and cleaned up, and for those wanting compatibility a module called CGI5.pm can be written. It will probably be very popular, like p5 regexes ...
Re: the CGI.pm in Perl 6
Trey Harris schrieb: I agree with the sentiment, but as a practical matter, not having HTML methods in CGI.pm could drastically limit Perl 6 adoption. Oh well. I thought it was common sense that it's a bad idea to mix code and markup. Who really wants to do itself this pain should use a separate module for that imho (or better a templating system like Template Toolkit). If Perl 5 programmers get used to how they can mechanistically port their programs to Perl 6, they will do so with the same sort of ah-hah moments you've posted about on the Pugs blog, and it will be a good experience. They can do: use perl5:CGI; if they want that legacy support. 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. An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. But then this new module cannot profit of the popularity of the name CGI.pm and many people will say Ah, Perl6 web development is stuck at the 10 years old Perl5 CGI.pm interface. I'll use (python|ruby( on rails)?|.+). That would be sad. now: use CGI; use CGI::HTMLgenerators; # Available separately, deprecated That'd be ok. Just my 2ct. -Thomas
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
Re: the CGI.pm in Perl 6
In a message dated Sat, 9 Sep 2006, Mark Stosberg writes: I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. I agree with the sentiment, but as a practical matter, not having HTML methods in CGI.pm could drastically limit Perl 6 adoption. If Perl 5 programmers get used to how they can mechanistically port their programs to Perl 6, they will do so with the same sort of ah-hah moments you've posted about on the Pugs blog, and it will be a good experience. In other words, if they can port at a very low level (more like paraphrasing a complicated text for a child than like translating from Chinese to English) they won't feel that *everything* has changed under their feet, and over time they'll start to nibble at more advanced features, and before long they'll be translating automatically rather than paraphrasing mechanically. But the HTML methods are used everywhere. And the more novitiate the programmer, the more likely they are to be using them spaghetti-like throughtout their code. If they discover that every time they see a Cstart_form it's going to entail new coding, they're going to rapidly get discouraged about porting to Perl 6. I'd suggest that perhaps a more workable solution is to just buck up and accept that the HTML methods have to get ported along with the rest of CGI.pm, but put them into a separate distribution and have documentation in Differences and its successors that say something like: was: use CGI ':standard'; now: use CGI; use CGI::HTMLgenerators; # Available separately, deprecated perhaps with some scary-sounding warnings about how you should only use the latter if you have lots of preexisting code needing the generators, that it's better to use these other good solutions, you may shoot your eye out, etc. etc. I know I seem to veer from wanting everything to change to wanting nothing change, but it really comes down to whether the changes will not just be good for us in an eat-your-spinach kind of way, but will lead to a more pleasant programming experience as well. Adoption of Perl 6 will depend on whether programmers like it, regardless of how stable or beautifully-architected its systems are. Trey
Re: the CGI.pm in Perl 6
In a message dated Sat, 9 Sep 2006, Mark Stosberg writes: I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. I agree with the sentiment, but as a practical matter, not having HTML methods in CGI.pm could drastically limit Perl 6 adoption. If Perl 5 programmers get used to how they can mechanistically port their programs to Perl 6, they will do so with the same sort of ah-hah moments you've posted about on the Pugs blog, and it will be a good experience. In other words, if they can port at a very low level (more like paraphrasing a complicated text for a child than like translating from Chinese to English) they won't feel that *everything* has changed under their feet, and over time they'll start to nibble at more advanced features, and before long they'll be translating automatically rather than paraphrasing mechanically. But the HTML methods are used everywhere. And the more novitiate the programmer, the more likely they are to be using them spaghetti-like throughtout their code. If they discover that every time they see a Cstart_form it's going to entail new coding, they're going to rapidly get discouraged about porting to Perl 6. I'd suggest that perhaps a more workable solution is to just buck up and accept that the HTML methods have to get ported along with the rest of CGI.pm, but put them into a separate distribution and have documentation in Differences and its successors that say something like: was: use CGI ':standard'; now: use CGI; use CGI::HTMLgenerators; # Available separately, deprecated perhaps with some scary-sounding warnings about how you should only use the latter if you have lots of preexisting code needing the generators, that it's better to use these other good solutions, you may shoot your eye out, etc. etc. I know I seem to veer from wanting everything to change to wanting nothing change, but it really comes down to whether the changes will not just be good for us in an eat-your-spinach kind of way, but will lead to a more pleasant programming experience as well. Adoption of Perl 6 will depend on whether programmers like it, regardless of how stable or beautifully-architected its systems are. Trey
Re: the CGI.pm in Perl 6
Darren Duncan wrote: P.S. I originally sent this to just Mark Stosberg yesterday, and he suggested I sent it to perl6-users for more exposure, so here it is, slightly edited. And here is my reply to Darren, slightly edited. I'm only interested in CGI.pm so much as it holds up my work on CGI::Application. As far as I'm aware, adding cookie support is all that's left to do that to meet my needs. So for the most part, I don't intend to be making design decisions for or against your arguments. I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. On the other hand, there is a real benefit to in being similar enough so that porting from Perl 5 is easy. Radical differences can forked into Web.pm or something. I'll provide some comments on your suggestions below. Note that I will make these changes myself if someone else doesn't. Great! 1. ALWAYS gather all GET/query-string variables that exist, regardless of whether this is a POST or GET query. The Perl 5 version currently discards any GET vars that are included in a POST request and doesn't provide any workaround save to uncomment a code line in CGI.pm itself. Eg, say you want to submit a POST form to this url: http://foo.com/bar/?screen=baz Stuff like that should just work, but for CGI.pm in Perl 5 it doesn't. I have to parse the query string myself if I get a POST request, to make that work, and its inane that Perl 5's CGI.pm doesn't just work with it. I see both sides to this and don't feel strongly about it. 2. Keep 2 distinct sets of query parameters, one each for GET (query string) and POST (HTTP body) variables, that are both initialized and can be appropriately read from and updated. They must be separate because it is legitimate to have variables with the same names in both places that must be kept distinct. Combining these is like combining cookie or session variable with either; all 4 are distinct things. I suggest that all accessors for these contain the words http get var(s) or http post var(s) in them respectively. For backwards computability, you could also keep param named functions which accesses a union of the above and the post ones take precedence in a name conflict. But the key thing is it must be possible+easy to use them separately. Practically every other web environment's basic built-ins, including ASP and PHP, correctly keep these separate, and its time for Perl's basics to join them. I agree here. 3. ALWAYS retain any multiple values for get and post vars. For ease of use, your accessors could look like http_post_var() and http_post_var_multi() etc, which fetch either just the first item as a scalar or an array ref having all the items (even if just one) respectively. I think this is already working. We always store values as arrays internally, and I think because of how Perl 6 works, it does the right thing if you expect a single value or an array returned. 4. Make UTF-8 the default HTTP response character encoding, and the default declared charset for text/* MIME types, and explicitly declare that this is what the charset is. The only time that output should be anything else, even Latin-1, is if the programmer specifies such. 5. Similarly, default to trying to treat the HTTP request as UTF-8 if it doesn't specify a character encoding; fall back to Latin-1 only if the text parts of the HTTP request don't look like valid UTF-8. I am not knowledgeable enough about this to haven an opinion. Currently CGI.pm-p6 defaults to Latin-1, apparently as a port for Perl 5. Since the related function was broken as recently as a few days ago, I know no one is depending on that default now, including me. 6. I suggest ditching the functional globals-storing CGI.pm interface and using the OO version only; much simpler. I made that change myself. It's OO-only now. I look forward to your commits! Once you start making changes, I'll let you know if you break anything CGI::Application depends on. It sounds like you probably won't. Mark -- http://mark.stosberg.com/
Re: the CGI.pm in Perl 6
At 3:11 PM -0500 9/9/06, Mark Stosberg wrote: I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. On the other hand, there is a real benefit to in being similar enough so that porting from Perl 5 is easy. Radical differences can forked into Web.pm or something. If you want to see something more radical, have a look at my first major CPAN modules from 2001ish. Mainly HTML::FormTemplate and CGI::Portable. Between those and their dependencies (HTML::EasyTags, Class::ParamParser, Data::MultiValuedHash, CGI::MultiValuedHash), was an entire and cleaner and more modular re-implementation of CGI.pm plus a few extras (and minus a few bits; I never implemented file upload handling). It is also more or less backwards compatible with CGI.pm where it makes sense. The combination is a bit large to be a CGI.pm replacement, but I think that a lot can be learned from this if one wants to make more significant CGI.pm improvements. Note that I am still using those modules of mine for my own personal web sites, but I'm not aware that they ever took off with other people in a big way. I also don't plan to straight-port them to Perl 6 since in large I don't know if they really offer anything people want that other web frameworks don't. I also don't have a big stake in them like I do with my current database-centric modules (where I'm more certain they can have a big impact). However, I'm sure the web modules can influence improvements to CGI.pm in Perl 6, and I will do so at an appropriate time. -- Darren Duncan
