in reply to Inserting CGI code in script tag

I agree with both Arguile and Boldra in that your question is slightly confusing.

It appears that what you are trying to do is to redirect to another CGI script ('test.cgi') from your script, of which you've presented a fragment. To do this using CGI.pm, you merely have to: 

print $q->redirect($refreshUrl);

[download]

This sends an HTTP header which has the same effect as putting the following line into the header of an HTML page (hence the name, "HTTP-EQUIV"): 

<META HTTP-EQUIV="Refresh" CONTENT="$refreshTime; URL=$refreshUrl">

[download]

Your script fragment does precisely the same thing in its last line (which prints the Location: header). In fact, you could get rid of all the other print statements to the same effect.

What's confusing is the relationship between $refreshFile and $refreshUrl. If you meant $refreshUrl to refer to the same file, the one you are creating on the fly, your file would be redirecting to itself in an endless loop.

BTW, the URL in the <SCRIPT> tag (src='http://www.test.com/cgi-bin/test.cgi') should refer to a javascript file, e.g., 'something.js', NOT to a perl script (unless that perl script is a CGI program that writes pure javascript code to its standard output).

Any code between the <SCRIPT> and </SCRIPT> tags ought to be javascript as well.

In either case, the javascript code executes at the BROWSER, not on the server.

dmm


You can give a man a fish and feed him for a day ...
Or, you can teach him to fish and feed him for a lifetime

Replies are listed 'Best First'.
Re: Re: Inserting CGI code in script tag
by Anonymous Monk on Oct 24, 2001 at 02:06 UTC
    Sorry about the confusing post. I only put in a fragment of the code and that is where some of it arises from. Essentially I have a module that does the following:

    Takes a subroutine as an argument (usually one that takes a long time to run)

    Forks off a child to process the subroutine code while the parent creates a temporary "analysis in progress" html page (that refreshes every so often). When the child is finished executing it creates another html page that prints any output from the subroutine, and then overwrites the "analysis in progress" page with the content of this page thus ending the refresh.

    I get tired of looking at that screen and wanted to give some kind of progress update and incorporate it into the module. So, in addition to the subroutine used to perform the actual work, I want to take another subroutine as an argument that can be used to give some kind of status on the update. In my case I wanted it to print the number of records that have been inserted into a db of the total number using some DBI code. What I could do with the second subroutine is create a temporary CGI fine that the refresher page redirects to. However, I was hoping to just be able to have the progress subroutine print to the browser directly, that is without needing to generate this temporary cgi file. That is the basis of my question. There may be a much easier way to do this, I am not sure. I hope this makes things clearer.

    Also, I was using the script tag to point to the cgi program for historical reasons. The cgi script outputs document.write commands so that part of the script is fine. However, I should just use the redirect as it is easier.

    Thanks again.

    -jim
[reply]

      The problem with this kind of thing in general is that the web is request/response based. Server-push (that is, having the progress subroutine print to the browser directly) is difficult to get right.

      I've had some success with a similar problem by storing the process id of the forked process (or some other identifying value) in a session record (perhaps in a database table), and passing the key to that session record as a parameter to a progress script (e.g., "test_progress.cgi?session_key=whatever"). The progress script can then use the session key to look up the process id (or whatever), check whatever it needs to check, and regenerate the "in progress" page with a redirect to itself after some amount of time.

      When the process is complete, the progress script can immediate redirect to a third script (or perhaps the original one, with a different parameter to identify the new context) for display of the output, which must have been stored somehow by the forked process, in a location identifiable by the same session key--I often use a generated filename in /tmp, with the hostname and process ID of the background process somehow incorporated in the filename, as the session key.

      There can be irritating reliability (i.e., timeout) problems with your original idea of rewriting the page from the forked process. It may or may not work, depending upon how long the background process takes and other factors beyond your control, such as browser dependencies, server-side loading, etc., and whether or not the progress page itself contains </BODY> and </HTML> tags.

      dmm

      
You can give a man a fish and feed him for a day ...
Or, you can teach him to fish and feed him for a lifetime
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom