the CGI.pm in Perl 6

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. To those of you working on (or wanting to use) the Perl 6 native CGI.pm, Concerning the work you've been doing lately in ge

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

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 sim

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

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

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 wi

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 separa

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

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 comp

Re: the CGI.pm in Perl 6

On Tue, Sep 12, 2006 at 05:18:19PM +0300, Amir E. Aharoni wrote: > 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 ... Hear hear! I wonder how

Re: the CGI.pm in Perl 6

On Wed, 13 Sep 2006, David Cantrell wrote: > I wonder how many people really use the HTML-generating bits of CGI.pm? I'd guess a lot, since they are prominently documented in the CGI.pm documentation and are used extensively throughout many of the examples there. It would be quite natural for

Re: the CGI.pm in Perl 6

Actually, I used them a few times. I agree the model used for html generation is inadequate for most any serious usage. However, if you need to dynamicaly generate forms CGI.pm is unmatched. A modernized equavalent for them would still be very usefull IMHO. Though I agree it might be better put in

Re: the CGI.pm in Perl 6

On 9/13/06, Leon Timmermans <[EMAIL PROTECTED]> wrote: On the other HTML outputting functions: They never really belonged in CGI in the first place I guess. There is no reason they cannot be generalized to XML outputting and be put in an appropriate library. There is, actually. HTML ne XML. H

Re: the CGI.pm in Perl 6

Aankhen skribis 2006-09-14 17:00 (-0700): > There were a few discussions with Juerd and others in #perl6 about > CGI.pm in Perl 6... I've been following the discussion with great interest, and will summarize my thoughts here soon. -- korajn salutojn, juerd waalboer: perl hacker <[EMAIL PROT

Re: the CGI.pm in Perl 6

> "Andy" == Andy Dougherty <[EMAIL PROTECTED]> writes: Andy> On Wed, 13 Sep 2006, David Cantrell wrote: >> I wonder how many people really use the HTML-generating bits of CGI.pm? Andy> I'd guess a lot, since they are prominently documented in the CGI.pm Andy> documentation and are used exten

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,

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

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 C it's going to entail > new c

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 sh

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 bu

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

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 se

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

Re: the CGI.pm in Perl 6

Randal L. Schwartz skribis 2006-09-19 8:16 (-0700): > No, it's an *integrated* task. The form-generation stuff needs tight coupling > with the getting (and setting) of the incoming param values. Integrated task? Tight coupling? If I didn't know you, I'd immediately say you have no idea what you'

Re: the CGI.pm in Perl 6

* Randal L. Schwartz [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 jus

Re: the CGI.pm in Perl 6

> "Steve" == Steve Pitchford <[EMAIL PROTECTED]> writes: Steve> To be honest I'm not sure I follow your argument. Why does populating a form Steve> from incoming form data require "closer integration" Steve> than, say, pulling it out of a database and populating a form for further Steve> edit

Re: the CGI.pm in Perl 6

* Randal L. Schwartz [2006-09-20 19:30]: > To get this to work right, whatever I use for HTML generation > needs to know how to get incoming params. Admittedly, the > interface is simple, but it would have to know if I'm using a > functional form with a hidden object (use CGI qw/param/) Which is

Re: the CGI.pm in Perl 6

A. Pagaltzis skribis 2006-09-20 22:01 (+0200): > With roles in P6, you can even make this even simpler. You could > make the HTML generator a role which can be composed onto any > object that `does ParamQuery`. I think it's time we moved away from the param method, and started using a hash. In fac

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 ow

Re: the CGI.pm in Perl 6

A. Pagaltzis skribis 2006-09-20 22:39 (+0200): > * 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?

Re: the CGI.pm in Perl 6

* Juerd <[EMAIL PROTECTED]> [2006-09-21 00:45]: > And I wouldn't want the nullbyte mistake again. Let's just > stick to the last given value instead. Nobrainer. The nullbyte thing was a Perl-4-ism. > Also, I want parameters to be able to do a certain Upload role, > which adds terribly useful meth

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.param.'@'; : my @bar = @ $q.param; That should work but my preference is just my @bar = $q.param[]; That is, empty .[] has the same arrayifying semantics as @. (This is curr

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.param[]; > 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 empt

Re: the CGI.pm in Perl 6

On Tue, Sep 19, 2006 at 08:16:26AM -0700, 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

Re: the CGI.pm in Perl 6

Larry Wall skribis 2006-09-21 15:24 (-0700): > : > 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? > Oh, I expect .[()] would work for that. Why y

Re: the CGI.pm in Perl 6

On Thu, Sep 21, 2006 at 10:10:04AM +0200, Juerd wrote: : Larry Wall skribis 2006-09-20 16:34 (-0700): : > That should work but my preference is just : > my @bar = $q.param[]; : > That is, empty .[] has the same arrayifying semantics as @. (This is : > currently b0rken in pugs though.) Likewis

Re: the CGI.pm in Perl 6

On Fri, Sep 22, 2006 at 12:34:47AM +0200, Juerd wrote: : Larry Wall skribis 2006-09-21 15:24 (-0700): : > : > 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 emp

Web.pm or something (Re: the CGI.pm in Perl 6)

At 3:21 PM +0200 9/12/06, Thomas Wittek wrote: 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...). I strongly suggest that if we're going to do things this way, which sounds like a good idea

Charsets in HTTP (was: the CGI.pm in Perl 6)

* Darren Duncan <[EMAIL PROTECTED]> [2006-09-09 20:40]: > 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 Lati

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 man

Re: Web.pm or something (Re: the CGI.pm in Perl 6)

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 t

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 reus

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 modu

Re: Charsets in HTTP (was: the CGI.pm in Perl 6)

A. Pagaltzis skribis 2006-09-16 19:38 (+0200): > * Darren Duncan <[EMAIL PROTECTED]> [2006-09-09 20:40]: > > 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 onl

Re: Charsets in HTTP (was: the CGI.pm in Perl 6)

At 7:38 PM +0200 9/16/06, A. Pagaltzis wrote: * Darren Duncan <[EMAIL PROTECTED]> [2006-09-09 20:40]: 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 t

Re: Charsets in HTTP (was: the CGI.pm in Perl 6)

* Juerd <[EMAIL PROTECTED]> [2006-09-16 22:15]: > My thoughts: > > * Default Content-Type header of "text/html; charset=UTF-8". > * Default output encoding of UTF-8. > * When a new Content-Type is set, but no new encoding > * Keep the default output encoding of UTF-8 >

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 C

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 thi

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

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 c

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

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

Mark Stosberg skribis 2006-09-16 22:04 (-0500): > As far as I'm aware, no work on CGI::Session for Perl 6 has started yet. I'm happy about that, because this module must not have "CGI" in its name. -- korajn salutojn, juerd waalboer: perl hacker <[EMAIL PROTECTED]>

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

It sounds like the name of HTTP is more appropriate: HTTP::Request ...uri, pathinfo, params, method, headers, etc. HTTP::Request::Session ...adds to HTTP::Request to provide session() method HTTP::Response ...response code, content, headers, etc. HTTP::Response::JSON

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

Ian Langworth skribis 2006-09-19 19:02 (-0700): > It sounds like the name of HTTP is more appropriate: > HTTP::Request > ...uri, pathinfo, params, method, headers, etc. > (etc) Well, yes and no. HTTP is today's web protocol standard, but may not be with us forever. I was thinking of getting

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

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

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 gen

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

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

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

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

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 h

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

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

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

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 t

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

> "Fagyal" == Fagyal Csongor <[EMAIL PROTECTED]> writes: Fagyal> As a side note I also have to add that I really dislike the Fagyal> "html-functions" CGI.pm currently has. Creating the representation is Fagyal> the task of the designer, not the programmer. It's almost like "echo" Fagyal> in PH

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

* Randal L. Schwartz [2006-09-20 19:30]: > "Fagyal" == Fagyal Csongor <[EMAIL PROTECTED]> writes: >> yet I never needed those HTML generating methods. > > You've never made a sticky form then. False dilemma. You can create sticky forms conveniently without using CGI.pm’s HTML generation stuff. Y

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

On 9/20/06, Fagyal Csongor <[EMAIL PROTECTED]> wrote: And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. If those are modules to generate markup, I don't see why they should under the Web namespace. Ther

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

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.

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

On 9/21/06, Juerd <[EMAIL PROTECTED]> wrote: Because they speak the same language. That is: they know about arguments passed via forms, and the preferred output language (xhtml? html?). Ah, I didn't think of that. My bad. Roles for all these things sound great to me. :-) Aankhen

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

> ""A" == "A Pagaltzis" <[EMAIL PROTECTED]> writes: "A> * Randal L. Schwartz [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 stic

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

Randal L. Schwartz skribis 2006-09-21 9:15 (-0700): > We need the same thing for Perl6: "If you're going to do simple web stuff, > please use MUMBLE module". And MUMBLE better have tight integration of param > processing and sticky form generation, as well as good header generation for > cookies

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

Randal L. Schwartz wrote: And MUMBLE better be included *with* Perl6. I disagree. Anything that can be left out of the base Perl6 distro should be. * It's too inflexible, so it doesn't allow for a new improved module to come along to replace it. * It requires more from the Perl6 maintaine

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

* Randal L. Schwartz [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 c

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

Who uses CGI.pm HTML generation? (was: Re: the CGI.pm in Perl 6)

David Cantrell wrote: > > I wonder how many people really use the HTML-generating bits of CGI.pm? > I know I never have, nor have they been used that I can remember > anywhere that I've worked, or in any of the non-work projects I've > collaborated in. It's always been 'print ""' or more recently

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 >

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

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 h

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 h

Re: use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)

Mark Stosberg skribis 2006-09-16 21:30 (-0500): > 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 fo

Re: use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)

Mark Stosberg skribis 2006-09-16 21:32 (-0500): > 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. I base my thoughts on Perl 6, not Pugs specifically. It'

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

Juerd wrote: Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's "textfield" isn't it? So that would make this one "passwor

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

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

Darren Duncan skribis 2007-04-14 23:37 (-0700): > Presumably Juerd will get back to these when he has the tuits, but > meanwhile you could try improving what he started. Indeed. Please read these two posts to this list: http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8

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

At 10:23 AM +0200 4/15/07, Juerd Waalboer wrote: Please read these two posts to this list: http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=st&q=juerd+web+development&rnum=1#a209deddfadad19b http://groups.google.nl/group/perl.perl6.users/brow

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

Hi, Jacinta Richardson wrote: > Juerd wrote: [CGI.pm et al] >> Yes, this needs to be redesigned completely. Are you volunteering? > > Is this still needed? If so yes, I'm now volunteering! Where'd you > like me to start? I'd like to point out that this might be a good idea for a perl6 microgra