Darren Duncan wrote: > P.S. I originally sent this to just Mark Stosberg yesterday, and he > suggested I sent it to perl6-users for more exposure, so here it is, > slightly edited.
And here is my reply to Darren, slightly edited. I'm only interested in CGI.pm so much as it holds up my work on CGI::Application. As far as I'm aware, adding cookie support is all that's left to do that to meet my needs. So for the most part, I don't intend to be making design decisions for or against your arguments. I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. On the other hand, there is a real benefit to in being similar enough so that porting from Perl 5 is easy. Radical differences can forked into Web.pm or something. I'll provide some comments on your suggestions below. > > Note that I will make these changes myself if someone else doesn't. Great! > > 1. ALWAYS gather all GET/query-string variables that exist, regardless > > of whether this is a POST or GET query. The Perl 5 version currently > > discards any GET vars that are included in a POST request and doesn't > > provide any workaround save to uncomment a code line in CGI.pm itself. > > > > Eg, say you want to submit a POST form to this url: > > > > http://foo.com/bar/?screen=baz > > > > Stuff like that should just work, but for CGI.pm in Perl 5 it doesn't. > > I have to parse the query string myself if I get a POST request, to make > > that work, and its inane that Perl 5's CGI.pm doesn't just work with it. I see both sides to this and don't feel strongly about it. > > 2. Keep 2 distinct sets of query parameters, one each for GET (query > > string) and POST (HTTP body) variables, that are both initialized and > > can be appropriately read from and updated. They must be separate > > because it is legitimate to have variables with the same names in both > > places that must be kept distinct. > > > > Combining these is like combining cookie or session variable with > > either; all 4 are distinct things. I suggest that all accessors for > > these contain the words "http get var(s)" or "http post var(s)" in them > > respectively. For backwards computability, you could also keep "param" > > named functions which accesses a union of the above and the post ones > > take precedence in a name conflict. But the key thing is it must be > > possible+easy to use them separately. > > > > Practically every other web environment's basic built-ins, including ASP > > and PHP, correctly keep these separate, and its time for Perl's basics > > to join them. I agree here. > > 3. ALWAYS retain any multiple values for get and post vars. For ease > > of use, your accessors could look like "http_post_var()" and > > "http_post_var_multi()" etc, which fetch either just the first item as a > > scalar or an array ref having all the items (even if just one) > > respectively. I think this is already working. We always store values as arrays internally, and I think because of how Perl 6 works, it does the right thing if you expect a single value or an array returned. > > 4. Make UTF-8 the default HTTP response character encoding, and the > > default declared charset for text/* MIME types, and explicitly declare > > that this is what the charset is. The only time that output should be > > anything else, even Latin-1, is if the programmer specifies such. > > > > 5. Similarly, default to trying to treat the HTTP request as UTF-8 if > > it doesn't specify a character encoding; fall back to Latin-1 only if the > > text parts of the HTTP request don't look like valid UTF-8. I am not knowledgeable enough about this to haven an opinion. Currently CGI.pm-p6 defaults to Latin-1, apparently as a port for Perl 5. Since the related function was broken as recently as a few days ago, I know no one is depending on that default now, including me. > > 6. I suggest ditching the functional globals-storing CGI.pm interface > > and using the OO version only; much simpler. I made that change myself. It's OO-only now. I look forward to your commits! Once you start making changes, I'll let you know if you break anything CGI::Application depends on. It sounds like you probably won't. Mark -- http://mark.stosberg.com/
