CGI Session management (was Re: the CGI.pm in Perl 6)

------=_Part_292401_18148067.1158006715648
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
>
> 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

------=_Part_292401_18148067.1158006715648--
0
michael
9/11/2006 8:31:55 PM
perl.perl6.users 1545 articles. 0 followers. Follow

33 Replies
2038 Views

Similar Articles

[PageSpeed] 41

--CUFRbl9plnVqmeZZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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'] =3D '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.

--=20
  Yuval Kogman <nothingmuch@woobling.org>
http://nothingmuch.woobling.org  0xEBD27418


--CUFRbl9plnVqmeZZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFBoVAVCwRwOvSdBgRAvxuAJ42JAGKXuW5rFG0iKhloKXHtrSLQACggFj1
Rajc2UQFrN4gC4ZYZUJgU3U=
=felr
-----END PGP SIGNATURE-----

--CUFRbl9plnVqmeZZ--
0
nothingmuch
9/12/2006 10:00:32 AM
* Yuval Kogman <nothingmuch@woobling.org> [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/>
0
pagaltzis
9/16/2006 5:16:13 PM
> 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  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/16/2006 7:05:57 PM
> 
> 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
0
mark
9/17/2006 3:04:18 AM
Mark Stosberg skribis 2006-09-16 22:04 (-0500):
> As far as I'm aware, no work on CGI::Session for Perl 6 has started yet.

I'm happy about that, because this module must not have "CGI" in its
name. 
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/17/2006 9:29:17 AM
It sounds like the name of HTTP is more appropriate:

   HTTP::Request
      ...uri, pathinfo, params, method, headers, etc.

   HTTP::Request::Session
      ...adds to HTTP::Request to provide session() method

   HTTP::Response
      ...response code, content, headers, etc.

   HTTP::Response::JSON
      ...extends response.write() to encode JSON

Maybe CGI.pm could adapt these to the CGI environment and ecapsulate
their functionality.

Maybe it's too servlety.

On 9/17/06, Juerd <juerd@convolution.nl> wrote:
> Mark Stosberg skribis 2006-09-16 22:04 (-0500):
> > As far as I'm aware, no work on CGI::Session for Perl 6 has started yet.
>
> I'm happy about that, because this module must not have "CGI" in its
> name.
> --
> korajn salutojn,
>
>   juerd waalboer:  perl hacker  <juerd@juerd.nl>  <http://juerd.nl/sig>
>   convolution:     ict solutions and consultancy <sales@convolution.nl>
>


-- 
Ian Langworth
0
ian
9/20/2006 2:02:11 AM
Ian Langworth skribis 2006-09-19 19:02 (-0700):
> It sounds like the name of HTTP is more appropriate:
>   HTTP::Request
>      ...uri, pathinfo, params, method, headers, etc.
> (etc)

Well, yes and no. HTTP is today's web protocol standard, but may not be
with us forever. I was thinking of getting these HTTP modules from LWP
(and Perl6-ify them, and change some method names), and then letting
Web::Blah inherit from HTTP::Blah as a first implementation.

> Maybe CGI.pm could adapt these to the CGI environment and ecapsulate
> their functionality.

Maybe I think that that should absolutely not belong in a root
namespace. Though yes, CGI.pm could be in a directory, like Web/CGI.pm
:)

> Maybe it's too servlety.

No, it's perfect, if we change just a few things (mostly the number of
"convenience methods" that are just delegations, and introduce some real
convenience instead.)
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/20/2006 9:09:49 AM
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.
0
concept
9/20/2006 9:28:52 AM
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: streawkceur@jabber.i-pobox.net
0
mail
9/20/2006 12:03:29 PM
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  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/20/2006 12:21:28 PM
Thomas Wittek wrote:

[...]

>But I think that it would be a good idea to create a clean, "servlety"
>foundation, upon which you still can implement a 200 lines
>CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks.
>  
>
That sounds nice.

- Cs.
0
concept
9/20/2006 12:52:19 PM
Juerd wrote:

>Fagyal Csongor skribis 2006-09-20 11:28 (+0200):
>  
>
>>You rarely do real HTTP handling when you use CGI.
>>    
>>
>You may not, but many people do a lot of these things.
>  
>
Actually me, too. Not with CGI.pm, though.
I tend to use CGI::Simple for form/param parsing, Template.pm for 
template processing, LWP::Simple for... well, HTTP handling (kind of...) 
and so on and so on.

>And when you don't, the datastructures are currently parsed and filled
>anyway, so I don't know why you say it'd be too inefficient.
>  
>
Inefficient was probably a bad choice of word.
I would rather say: I would not like to see Perl6's CGI.pm as a monster 
module, which has one part everyone uses, and one hundred other parts 
that some uses, because I feel those parts should be put into other 
modules.
I just feel quilty when I use (Perl5's) CGI.pm for such trivial tasks as 
parameter parsing. Feels like... say, using MIME::Lite for *sending* 
mail not *constructing*.
Or maybe... you know, I have a Windows XP installed at home. The one 
thing I use it for is to run dvdsrhink :)) That's a big price for 10G of 
discspace :)

As a side note I also have to add that I really dislike the 
"html-functions" CGI.pm currently has. Creating the representation is 
the task of the designer, not the programmer. It's almost like "echo" in 
PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP, 
mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those 
HTML generating methods. To me, <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
0
concept
9/20/2006 1:43:26 PM
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
0
concept
9/20/2006 1:57:54 PM
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


0
jarich
9/20/2006 2:13:45 PM
Fagyal Csongor skribis 2006-09-20 15:43 (+0200):
> Inefficient was probably a bad choice of word.
> I would rather say: I would not like to see Perl6's CGI.pm as a monster 
> module, which has one part everyone uses, and one hundred other parts 
> that some uses, because I feel those parts should be put into other 
> modules.

Perl 6's Web toolkit, even with all these classes, is likely to be much
lighter than Perl 5's CGI.pm with :standard.

But note that especially if it is a well designed bundle of
classes/roles, you can pick exactly those things that you need, and
leave all others out. That's part of the reason why you should separate
things. 

> As a side note I also have to add that I really dislike the 
> "html-functions" CGI.pm currently has. Creating the representation is 
> the task of the designer, not the programmer.

That's an ideal world. Many programmers have to hack some HTML
themselves. I do think that they're far better off with raw HTML, but
there are people who prefer the generation methods, and we should try to
make everyone happy, not just ourselves.

> To me, <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.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/20/2006 2:17:11 PM
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  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/20/2006 2:23:44 PM
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

0
concept
9/20/2006 2:38:06 PM
>>>>> "Fagyal" == Fagyal Csongor <concept@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.

-- 
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!
0
merlyn
9/20/2006 3:16:05 PM
* Randal L. Schwartz <merlyn@stonehenge.com> [2006-09-20 19:30]:
> "Fagyal" == Fagyal Csongor <concept@conceptonline.hu> writes:
>> yet I never needed those HTML generating methods.
> 
> You've never made a sticky form then.

False dilemma. You can create sticky forms conveniently without
using CGI.pm’s HTML generation stuff. You can use HTML::Template,
HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on?

C’mon merlyn, you’ve been around long enough to know about CPAN
and realise that your statement is transparently fallacious.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
9/20/2006 7:53:01 PM
On 9/20/06, Fagyal Csongor <concept@conceptonline.hu> wrote:
> And maybe expand Web::HTML something like:
> Web::Markup::HTML
> Web::Markup::XHTML
> Web::Markup::WML
> etc...
> But that's might as well be too much.

If those are modules to generate markup, I don't see why they should
under the Web namespace.  There needs to be a Web.pm toolkit (or
something similar), but that's mostly an amalgamation of other
modules.

Aankhen
0
aankhen
9/21/2006 1:32:39 AM
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 :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.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/21/2006 8:26:30 AM
Randal L. Schwartz wrote:

>>>>>>"Fagyal" == Fagyal Csongor <concept@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

0
concept
9/21/2006 8:59:01 AM
>>>>> ""A" == "A Pagaltzis" <pagaltzis@gmx.de> writes:

"A> * Randal L. Schwartz <merlyn@stonehenge.com> [2006-09-20 19:30]:
>> "Fagyal" == Fagyal Csongor <concept@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.

-- 
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!
0
merlyn
9/21/2006 4:15:11 PM
On 9/21/06, Juerd <juerd@convolution.nl> wrote:
> Because they speak the same language. That is: they know about arguments
> passed via forms, and the preferred output language (xhtml? html?).

Ah, I didn't think of that.  My bad.  Roles for all these things sound
great to me. :-)

Aankhen
0
aankhen
9/21/2006 10:17:47 PM
Randal L. Schwartz skribis 2006-09-21  9:15 (-0700):
> We need the same thing for Perl6: "If you're going to do simple web stuff,
> please use MUMBLE module".  And MUMBLE better have tight integration of param
> processing and sticky form generation, as well as good header generation for
> cookies and redirects.  In other words, at least two thirds of what CGI.pm
> does for me now.  And MUMBLE better be included *with* Perl6.

To a certain extent, I agree.

What do you think of the Web MUMBLE that I proposed? I think I've
expressed it in enough detail now, for you to form an opinion.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
9/21/2006 11:48:13 PM
Randal L. Schwartz wrote:
> And MUMBLE better be included *with* Perl6.

I disagree. Anything that can be left out of the base Perl6 distro 
should be.

* It's too inflexible, so it doesn't allow for a new improved module to 
come along to replace it.

* It requires more from the Perl6 maintainers.

* It's impossible for everyone to agree on what should be core because 
everyone uses Perl6 for different applications.

* It's unnecessary bloat.

But this has all been "discussed" before...

Randy.
0
ml
9/22/2006 12:01:52 AM
* Randal L. Schwartz <merlyn@stonehenge.com> [2006-09-22 01:25]:
> HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not* in
> core. CGI.pm was. One stop shopping. Easy to describe to
> people.

That still doesn’t prove that tight coupling is necessary between
parameter parsing and HTML generation.

The concept of core is getting a do-over for Perl 6 anyway.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
9/22/2006 12:24:40 AM
Randal L. Schwartz wrote:

>>>>>>""A" =3D=3D "A Pagaltzis" <pagaltzis@gmx.de> writes:
>>>>>>           =20
>>>>>>
>
>"A> * Randal L. Schwartz <merlyn@stonehenge.com> [2006-09-20 19:30]:
> =20
>
>>>"Fagyal" =3D=3D Fagyal Csongor <concept@conceptonline.hu> writes:
>>>     =20
>>>
>>>>yet I never needed those HTML generating methods.
>>>>       =20
>>>>
>>>You've never made a sticky form then.
>>>     =20
>>>
>
>"A> False dilemma. You can create sticky forms conveniently without
>"A> using CGI.pm=E2=80=99s HTML generation stuff. You can use HTML::Temp=
late,
>"A> HTML::FillInFrom, HTML::Widget, CGI::FormBuilder=E2=80=A6 should I g=
o on?
>
>"A> C=E2=80=99mon merlyn, you=E2=80=99ve 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 stuf=
f,
>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=20
bunch of (CPAN6) modules.

- Fagzal

0
concept
9/22/2006 8:05:33 AM
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
0
jarich
4/15/2007 2:53:14 AM
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
0
darren
4/15/2007 6:37:54 AM
Darren Duncan skribis 2007-04-14 23:37 (-0700):
> Presumably Juerd will get back to these when he has the tuits, but 
> meanwhile you could try improving what he started.

Indeed.

Please read these two posts to this list:
http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=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,
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <juerd@juerd.nl>  <http://juerd.nl/sig>
  convolution:     ict solutions and consultancy <sales@convolution.nl>
0
juerd
4/15/2007 8:23:20 AM
At 10:23 AM +0200 4/15/07, Juerd Waalboer wrote:
>Please read these two posts to this list:
>http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=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
0
darren
4/15/2007 8:59:37 AM
--------------enig599775C7F617DE6A5E99ACDB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Jacinta Richardson wrote:
> Juerd wrote:
[CGI.pm et al]
>> Yes, this needs to be redesigned completely. Are you volunteering?
>=20
> 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=3D07/03/22/1542235

Afaict so far only 2 out of 10 are granted, so ideas and applications
are welcome.

Cheers,
Moritz

--=20
Moritz Lenz
http://moritz.faui2k3.org/ -  http://sudokugarden.de/ - http://perl-6.de/=



--------------enig599775C7F617DE6A5E99ACDB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGIfRgAAkekJBI0yIRAnMNAKDkbATOe/gq7Rc6V/m6riaVzvIIKwCg+oee
fa/maH8TyOJTc+EG8ZhjKHY=
=NVt5
-----END PGP SIGNATURE-----

--------------enig599775C7F617DE6A5E99ACDB--
0
moritz
4/15/2007 9:46:05 AM
Reply: