CGI Session management (was Re: the CGI.pm in Perl 6)
Michael Snoyman
>
> 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
Yuval Kogman
> 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.
Pleeeeeaseeeee... nooooo...
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 <nothi...@woobling.org>
http://nothingmuch.woobling.org 0xEBD27418
A. Pagaltzis
> 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/>
Juerd
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 <ju...@juerd.nl> <http://juerd.nl/sig>
convolution: ict solutions and consultancy <sa...@convolution.nl>
Mark Stosberg
> 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
Juerd
> 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.
Ian Langworth
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.
--
Ian Langworth
Juerd
> It sounds like the name of HTTP is more appropriate:
> HTTP::Request
> ...uri, pathinfo, params, method, headers, 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.)
Fagyal Csongor
> 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.
Thomas Wittek
> 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: strea...@jabber.i-pobox.net
Juerd
> 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.
Fagyal Csongor
[...]
>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.
Fagyal Csongor
>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, <imho>it 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
(1.2) specification (read *STDIN, write to *STDOUT, parse %ENV , that
is) and do nothing more. To stuff CGI::* with CGI::HTML, CGI::Whatever
is another story. As the matter of fact, I would rather rename the
current CGI::Simple to CGI, and CGI to Web::CGI or CGI::HTML or
something like that.
You know... as the matter of fact, I think we are only arguing about
namespace usage here :))
- Fagzal
Fagyal Csongor
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
Jacinta Richardson
> # 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
Juerd
> 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, <imho>it 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.
Juerd
> 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.
Fagyal Csongor
[...]
>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
Randal L. Schwartz
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, <imho>it 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
<mer...@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!
A. Pagaltzis
>
> 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.
Aankhen
> 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
Juerd
> 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 :type<xhtml> :html <$web>;
...;
print img(...); # <img .../>
I'm dreaming that :type<xhtml> 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.
Fagyal Csongor
>>>>>>"Fagyal" == Fagyal Csongor <con...@conceptonline.hu> 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, <imho>it 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
Aankhen
> 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
Randal L. Schwartz
"A> * Randal L. Schwartz <mer...@stonehenge.com> [2006-09-20 19:30]:
>> "Fagyal" == Fagyal Csongor <con...@conceptonline.hu> 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.
Juerd
> 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.
Randy W. Sims
> 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.
A. Pagaltzis
> 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.
Fagyal Csongor
>>>>>>""A" == "A Pagaltzis" <paga...@gmx.de> writes:
>>>>>>
>>>>>>
>
>"A> * Randal L. Schwartz <mer...@stonehenge.com> [2006-09-20 19:30]:
>
>
>>>"Fagyal" == Fagyal Csongor <con...@conceptonline.hu> 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
Jacinta Richardson
> 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
Darren Duncan
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
Juerd Waalboer
> 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=st&q=juerd+web+development&rnum=1#a209deddfadad19b
http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/2e67c41cf3bd5e35/5db1c4513fb847ff?lnk=st&q=juerd+web+development&rnum=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,
Darren Duncan
>Please read these two posts to this list:
>http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=st&q=juerd+web+development&rnum=1#a209deddfadad19b
>http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/2e67c41cf3bd5e35/5db1c4513fb847ff?lnk=st&q=juerd+web+development&rnum=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
Moritz Lenz
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/