how to modify text in html form from python

[Philippe C. Martin]

Mike,

Again, thanks.

By plugin I mean the browsers' extensions: ex:
http://roachfiend.com/archives/2004/12/08/how-to-create-firefox-extensions/#more-4.
IE has the same type or resorts also to activeX components.

Right now I know how to program that guy to open a url....

I guess I need to some thinking before I ask more questions.

Regards,

Philippe






Mike Meyer wrote:

> "Philippe C. Martin" <pmartin at snakecard.com> writes:
>> Mike Meyer wrote:
>>> I don't know much about plugins.  I believe they get started when the
>>> page loads, which gives you a chance to do the authentication when you
>>> want it done.
>> Well not in this case actually: the user triggers the plugin which in
>> turn open the url, so the connection is "owned" by the plugin
> 
> I think we don't mean the same thing when we say "plugin". To me, a
> plugin is a bit of code that gets executed when the page is rendered
> to provide custom content with it's own behavior. Flash is probably
> the most popular example. Like I said, I don't know much about
> plugins, so they may be usable in other ways.
> 
>>> That won't work very well. HTML goes to the client to display. The
>>> server can put data in hidden form elements that code running on the
>>> client side can get to - and change - via the document object model
>>> (DOM). However, the only way to send the changed data back to the
>>> server is to get the client to submit the form. You can automate that,
>>> but the results will be disconcerting to the user: they load a page,
>>> and it reloads multiple times as the plugin exchanges data with the
>>> server.
>> Here again, I'm not dying for any page data to be visible: cannot the cgi
>> script and the plugin do their business before that ?
> 
> Not if you're using plugin as defined above. Pretty much anything that
> happens on the browser end is triggered by things happening in HTML -
> which means it has to be displayed. I don't know of any way to
> download something to the browser to run without rendering *something*
> in the browser window - even if it's only a blank plage.
> 
>>> The problem with this is that the apache<->browser connection isn't
>>> "a" connection, it's a series of HTTP request/repsonse
>>> pairs. Originally, this implied tearing down and setting up a TCP
>>> connection for every request. Modern software will leave the link open
>>> and reuse it - but modern software also tends to have multiple
>>> connetions open, so it can fetch images and other embedded objects in
>>> parallel.
>> I'm lost here, better do some more reading
> 
> HTTP is a stateless protocol. Every HTTP request goes the same: the
> client sends a request saying what object it wants from the
> server. The server reads the request, and sends back the response,
> which is a collection of HTTP headers and a string of bytes. There's
> lots more details invovled, and various things you can do to enhance
> the performance of the system, but functionally they all boil down to
> that.
> 
>>> You can make this work, but doing it like that requires making
>>> multiple HTTP requests via the browser, which will be
>>> disconcerting. I'd recommend taking the browser out of the loop. Have
>>> the plugin talk directly to the server to do the
>>> authentication. That's what the latest web buzzword (AJAX) does:
>>> client-side software makes independent requests of the server (or
>>> *any* server) to get data, and possibly updates the document the
>>> browser is viewing as a result of that.
>> Here I think it's OK as the plugin can "talk" to server prior to the
>> browser showing anything.
> 
> If you say so. But certainly not through the browser.
> 
>>> So here's a scenario: the first cgi script gets info from the smart
>>> card that puts it in a hidden form element and sends the page to the
>>> browser. The plugin - started when the page loads - uses the DOM to
>>> get that data, then makes an *independent* HTTP request to the server,
>>> thus passing whatever it generated from the data in the form field to
>>> a second cgi script. This happens several times, then the plugin
>>> changes the HTML form to put whatever the cgi script generated into
>>> the form, so that when the user finally submits the form, the third
>>> cgi script - the one that handles the submitted form - sees the data
>>> from the second script.
>>> Actually, the exchanges between the plugin and the server don't need
>>> to be HTTP requests. If you've got this working over some other TCP
>>> protocol, there's no reason you can't keep doing it that way.
>> Maybe that's my clue: can a cgi script, once triggered by a (let's say)
>> POST request, use back and forth file transfer with the client ? through
>> the _existing_ connection.
> 
> I honestly don't know. HTTP does a strict onetime turnaround - the
> client sends, then the server sends, then you're done. There are hooks
> in the protocol to allow a connection to be resused, but that's a
> different request/response pair, and generally handled by the server,
> not the cgi script. After all, the next request from the client may be
> for some static file instead of the output of a cgi script.
> 
> Having a cgi script start two-way communications on the connection may
> well work. But it won't be HTTP, and I wouldn't be at all surprised if
> one or more of the components in some web connections - proxies,
> caches, firewalls, etc. - choked on it. You're liable to get
> apparently random failures depending on all kinds of exotic things.
> 
>            <mike