[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-core
Subject:    Re: [PATCH] cgi.rb -- more GET/POST stuff
From:       Francis Hwang <sera () fhwang ! net>
Date:       2004-12-29 7:24:54
Message-ID: 8B0EE92A-596B-11D9-8C83-000A95DBF456 () fhwang ! net
[Download RAW message or body]

Much of the discussion about web programming techniques can be moved to 
ruby-talk, as others have suggested. Regarding the core CGI library, my 
guess is that many people who do extensive web programming don't use 
CGI very directly, instead they find some way to abstract it away into 
an interface they like to use. I know I do this, and rarely spend any 
time looking up the CGI RDoc. You could look up all the different Ruby 
web application frameworks to get a sense of all the different ways 
people abstract away CGI.

So if parts of the CGI library feel odd to you, it's not because nobody 
else has had that problem, I think it's because other people who have 
had that problem have elected to solve the problem on a non-core level, 
I think.

On Dec 28, 2004, at 10:24 PM, mde@state26.com wrote:

> Okay, the last little bit of follow up here ...
>
>> For what it's worth, using an invisible table for Web page layout is
>> possible not a good example to use when defending hacks versus
>> "brilliant discovery", as some may see it as tending more towards the
>> former.
>
> It's kind of funny, but that's exactly why I used that
> as an example. :) Anyone who worked with Web pages in
> the mid-nineties will remember how the "invisible table hack"
> (and that good ol' invisible spacer GIF trick -- those were
> the days) turned a medium which had been designed for dry,
> academic papers into a real publishing medium capable of
> handling an infinite diversity of formatting options.
>
> For the longest time, the invisible table "trick" was
> your only option for creating moderately complex page
> formatting -- until CSS finally came along to provide a
> bit of relief. Although I do feel compelled also to point
> out that despite the relentless pronouncements of CSS's
> superiority and correctness from the Standards Community, and
> the separation-of-content-and-presentation zealot-types, in
> reality CSS's padding/width property interactions are just plain
> broken, and you can't even do the simple vertical centering of
> elements that was so easy and straightfoward in the table-based
> layout "hack" that it's supposed to be saving us all from.
>
> I'm not saying Standards are worthless, obviously, but a
> religious belief in their all-encompassing authority can
> seriously trip you up. I would much prefer a discussion on
> the real-world technical merits, because I actually *use*
> this stuff on a daily basis.
>
>> former.  In any event, there is a broad range of things one can do to
>> achieve certain results.  Maybe the real issue is whether a given tool
>> offers sufficient means to achieve a goal, even if that means is not 
>> one
>> everyone finds to be the easiest or the most familiar.
>
> This is actually a very good counter-argument. Parsing stuff
> out of cgi.query_string is trivial, as noted in previously. Ruby
> makes it way easy to customize and code around these limitations.
>
> However, I would argue that if a change does not penalize
> people familiar with the current implementation, and it makes
> it easier for a significant slice of the population -- and
> it does not contravene any Standards, what arguments are left
> against implementing it?
>
>> (On a side note, I never used the word "icky", nor referred to anyone 
>> as
>> a rube, a dolt, or as wet behind the ears. Those are your words, not
>> mine.  Sorry if I touched a raw nerve in my post.)
>
> To be completely fair, the word actually used was "distasteful,"
> which is a far more grown-up word than "icky," :-) Sorry if
> I overreacted. It was just the unfortunate combination of
> dismissive tone ("bad hack, "inexperienced") and apparent lack
> of actual knowlege about the specific subject in that bit of
> the post that got me a kind of testy. Again, serious apologies.
>
>> Most importantly, this is not the place to have a discussion on the 
>> pros
>> and cons of different techniques for Web site development.  Obviously
>> there is disagreement on the appropriate use of certain options, but
>> none of this means much to core Ruby development.
>
> Well, my original post was to submit what I hoped might be
> a helpful patch to cgi.rb, which is part of the Ruby core --
> and is of course the default library for Web programming with
> Ruby. Talking about a patch for the Web programming lib is
> unfortunately almost guaranteed to involve *actual examples
> of Web programming.* I realize it's not as sexy as stuff like
> threading and race conditions, so I'm really trying to keep
> it to a bare minimum.
>
>> I would prefer that any code in a Ruby Web lib adhere to any 
>> applicable
>> specs and RFCs; how people chose to exploit what falls out of this is
>> their business.  There are any number of ways to pass application
>> parameters in a URL (see del.icio.us, for example, or rails), and 
>> given
>> how trivial it is to extract the data I am skeptical of claims they
>> belong in the core library.
>
> That's kind of the issue. There's nothing in RFC 2616 (HTTP/1.1)
> even remotely specific enough about the actual form data and
> query string data to know whether it's acceptable or not. And
> the CGI spec of course specifies pulling the actual form
> data out of stdin for POSTs, but is silent on the issue of
> a query string in addition to the form data -- I'm guessing
> this is because the data is manifestly sitting there after the
> question mark on the requested file path, and it's up to the
> program to decide how (or whether) to allow the programmer to
> interact with that data.
>
> There's nothing in there that forbids it, but of course the
> idea is not specifically mentioned either. So it's obviously a
> good bet not to make any changes to what seems to be a really
> good implementation of the CGI spec -- especially when Ruby's
> flexibilty provides easy ways to code around limitations like
> that.
>
> There's something about that that seems kind of Amish to me
> (i.e., the people who don't use modern conveniences like
> electricity and cars because they are not mentioned in the
> Bible) -- but hey, it's called "cgi.rb," after all. I guess
> that in itself is a good reason not to make it into anything
> other than a solid example of old-school CGI.
>
> Thanks everybody.
>
>
> Matthew
>
>
>
>
>
>

Francis Hwang
http://fhwang.net/


[prev in list] [next in list] [prev in thread] [next in thread]