> From: "WALLYWORLD" <ran...@[EMAIL PROTECTED]
>
> HTML 3,0 streamlines the query process and makes it easier to
> perform queries on indexes. Performing an ISINDEX query under HYML
> 3.0 is a five step process.
This seems to me to be a very specific topic. In the general context
of CGI applications, why is it necessary to mention ISINDEX queries?
> CGI itself is a browser extension.
Of course. But it's built-in to all the current browsers, even
lynx. HTML FORM is presented to user, user fills it in then clicks
submit button, contents are urlencoded and passed to server which
p***** the contents to the CGI application which decodes them into
a 'map' (set of key->value pairs) once at start-up then queries
that 'map' through the course of the application. The full truth is
that CGI is partly a browser extension (the FORM contents encoder)
and partly a server extension (starting the CGI application instead
of just pulling up a static Web page, and passing the urlencoded
form contents to it somehow (environment variable or stdin)).
> Web gateways are programs or scripts used to access information
> that is not directly readable by the client.
Since the word "gateway" already has a different meaning in
InterNet jargon, this usage might confuse some people. Do you have
a good reason for introducing this ambiguity in the jargon?
Virtually every non-trivial WebServer application (CGI or PHP or
JSP or ASP etc.) consults some hidden database, such as login
account information at the very least in a majority of such
applications. My flashcard application for example consults the
user/password table, and after login consults that user's specific
status table, and updates that status table as the program runs,
and searches the master decks of flashcards to pull up the
individual flashcard at any moment. I see no reason this needs to
recycle the jargon word "gateway".Why not use a more common term,
such as "wrapper"? There are the basic data tables, and then there
is a "wrapper" around that data which presents some variant view of
that data to the user at any moment.
> The GET and POST methods of the FORM tag are both discussed.
> Only the HTTP GET method uses URL-encoded search strings.
That statement is grossly misleading. The only difference between
GET and POST method is that GET method appends the urlencoded info
after the URL, while the POST method transmits the urlencoded info
via standard input (stdin). As a result, a user can manually enter,
and can bookmark, the urlencoded data via GET method but not via
POST method. But once the CGI application has recogized the method
and loaded in the urlencoded data appropriately, everything after
that point is identical between GET and POST methods:
- Decoding into a 'map'.
- Referencing that 'map' as the application runs.
- Doing the business logic accordingly.
- Everything else involved, such as database queries, HTML output,
cookies.
> This applies when a server receives an URL-encoded search string,
> the server assigns the value of the search string to the
> QUERY-STRING variable in the HTTP header.
Only with the GET method. With POST method, the same data is passed via
stdin.
|
