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
Randal L. Schwartz wrote:
A == A Pagaltzis [EMAIL PROTECTED] writes:
A * Randal L. Schwartz merlyn@stonehenge.com [2006-09-20 19:30]:
Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes:
yet I never needed those HTML generating methods.
You've never made a
Larry Wall skribis 2006-09-20 16:34 (-0700):
That should work but my preference is just
my @bar = $q.parambar[];
That is, empty .[] has the same arrayifying semantics as @. (This is
currently b0rken in pugs though.) Likewise .{} is equivalen to %.
Nice, but what's the syntax for an
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
Randal L. Schwartz wrote:
Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes:
Fagyal As a side note I also have to add that I really dislike the
Fagyal html-functions CGI.pm currently has. Creating the representation is
Fagyal the task of the designer, not the programmer. It's
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.
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
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
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
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
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,
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
* Juerd [EMAIL PROTECTED] [2006-09-20 22:25]:
I think it's time we moved away from the param method, and
started using a hash.
I don’t know about that. The `param` method has the nice property
that it allows you to pretend everything’s a single value or to
use multi-valued params, at your own
On Thu, Sep 21, 2006 at 12:43:41AM +0200, Juerd wrote:
: my @bar = @{ $q-param-{ 'bar' } };
:
: my @bar = $q.parambar.'@';
: my @bar = @ $q.parambar;
That should work but my preference is just
my @bar = $q.parambar[];
That is, empty .[] has the same arrayifying semantics as @. (This
David == David Cantrell [EMAIL PROTECTED] writes:
But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.
David That's two tasks. It should be two modules.
No,
(Randal L. Schwartz) schrieb:
David == David Cantrell [EMAIL PROTECTED] writes:
David That's two tasks. It should be two modules.
No, it's an *integrated* task. The form-generation stuff needs tight
coupling
with the getting (and setting) of the incoming param values.
A separate module,
Randal L. Schwartz wrote:
David == David Cantrell [EMAIL PROTECTED] writes:
But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.
David
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
* Randal L. Schwartz merlyn@stonehenge.com [2006-09-19 21:25]:
The form-generation stuff needs tight coupling with the getting
(and setting) of the incoming param values. You couldn't just
use two random modules for that... they'd have to specifically
know about each other and work together.
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
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
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
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
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
* 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
* Trey Harris [EMAIL PROTECTED] [2006-09-10 23:50]:
But the HTML methods are used everywhere. And the more
novitiate the programmer, the more likely they are to be using
them spaghetti-like throughtout their code. If they discover
that every time they see a Cstart_form it's going to entail
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
, and the docs would
have to explain it, which is no picnic at all.
I disagree. Regardless of the details, a Perl 6 replacement for
CGI.pm *should* handle character set issues. Its users should simply
be able to pull out correctly interpreted ready-to-use Str values
when the HTTP request
On 9/14/06, Darren Duncan [EMAIL PROTECTED] wrote:
Having had some prior experience in tackling this problem (eg,
CGI::Portable), I will endeavour to work on / help with the Perl 6
analogy to HTTP::Request/Response, so to replace the use of
corresponding aspects of CGI.pm.
I really like this
Randal L. Schwartz skribis 2006-09-15 9:15 (-0700):
The thing that CGI.pm does is put in one place everything you need for a
simple web form. And there's an amazing number of applications for
this... putting a contact us page on an otherwise static site comes to mind
immediately.
Yes, it's
Juerd skribis 2006-09-15 23:26 (+0200):
Randal L. Schwartz skribis 2006-09-15 9:15 (-0700):
The thing that CGI.pm does is put in one place everything you need for a
simple web form. And there's an amazing number of applications for
this... putting a contact us page on an otherwise static
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
At 5:00 PM +0100 9/13/06, David Cantrell wrote:
On Tue, Sep 12, 2006 at 03:08:03PM -0700, Darren Duncan wrote:
The word CGI generally speaks to an old, weak, and relatively
inefficient technology ... modern proper stuff does not spin off a
separate process for each server request; it reuses
Thomas Wittek [EMAIL PROTECTED] writes:
An other acceptable solution would be to create a backwards
compatible P6 CGI.pm and create a new Web.pm with an all new
interface, like Mark suggested. But then this new module cannot
profit of the popularity of the name CGI.pm and many people will
say
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
Steffen Schwigon schrieb:
Thomas Wittek [EMAIL PROTECTED] writes:
An other acceptable solution would be to create a backwards
compatible P6 CGI.pm and create a new Web.pm with an all new
interface, like Mark suggested.
I would strongly expect the CGI module to do the same as it did for
the
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
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
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
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
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
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
(where I'm more certain they
can have a big impact). However, I'm sure the web modules can
influence improvements to CGI.pm in Perl 6, and I will do so at an
appropriate time.
-- Darren Duncan
43 matches
Mail list logo
