The simplest way would be to do something like this:

sub alert {
   print "Content-type: text/html\n\n";
   print "<script>alert('hello')</script>";
}
[download]

Please note that you're printing HTML, so "javascript:alert..." is just interpreted as text. You need to tell your browser that your're using a script (in fact, I believe it's more like <script language="Javascript">, but I never use it).

But if you're programming CGI (more than just this), you also might want to look into the CGI module, which offers you the "header" function, which takes care of the header. This way, you can also easily print "start_html" and "end_html", to provide somewhat more of an HTML page.

Unfortunately, that will leave you on a blank page. Not sure that that really is what is wanted.

                - Ant
                - Some of my best work - (1 2 3)

I understand what you're asking for, but I don't understand why. You're asking how to send some javascript to the browser to pop up an error dialog box. The thing is, you're still sending something to the browser. You might as well just send an error page instead. You mention "reload[ing] the whole page," so perhaps the page you're sending back is rather large. If this is the case, you can simply use a different template for the error page. But again, with such a small description of the actual problem, I don't quite understand what your reasons are.

> I understand what you're asking for, but I don't understand why.

The main reasons I'm not discussing why I need the solution fall into various categories that usually result in a thread going way off course very fast:

1) user interface design has nothing to do with the matter at hand. There is a technical problem at hand, and the discussion should be constrained within that scope. A UI design is one thing, and the lower level implementation blocks to achieve it are another. In the most simplistic explanation: if the task can be achieved by the browser, why aren't there standard ways for accessing that feature?

2) Once the flood gate is opened on whether any given choice for a UI element is appropriate, the real meat of the problem ((1)) is never discussed, and the thread goes so far afield, that the topic is never really settled. This, not to mention, a rapid growth of apathy from the readership.

3) While I certainly agree that only warranted uses should warrant in-depth discussion, it doesn't apply here. There is already strong precedent for the need and use of a "prompt box" found in applications in every facet of computers, platforms, and applications; its use and presence in javascript already illustrate that point, as well as similar UI features in Tk, et al.

4) Lastly, from a mere matter of pragmatism: one cannot and should not have to suddenly change their entire platform for development because of something as simple as a prompt box. That is, rewriting what could already be a huge undertaking in javascript "just because it has a promptbox" isn't justifiable. (whereas, rewriting the internals of a large program to take advantage of the speed and processing power of a major database backend may have justification.)

I apologize if this is stuff you already know, and I'm not trying to be patronizing, but I'd just like to put down some of my thoughts on the subject.

There is no way for a web server to talk to a web client without the web client having requested something. When you click on your "Submit" button, your web client sends a request to the web server to receive some data. Now, since your CGI script is sitting on the server, all it can do is passively wait for some data to be submitted to it. I'm sure you understand this, but it's worth reiterating.

By the time your CGI script gets the chance to do anything useful, the "whole page" has already been submitted. It's too late to say "wait wait, don't submit the page, but show a dialog box with an error instead." Thus your only realistic option is to "reload the whole page" with an error message. Now, as far as UI is concerned, at this point your error message can easily be displayed in a javascript popup window. This is not the issue. The issue is you want more integration between server and client than HTTP provides. This is a limitation you'll have to accept. Using tricks with frames may be an option, but might end up being more work than is feasible, and I usually try to avoid that kind of hack.

Of course, another solution is to move all this processing to the client, so you can check before the submit happens. You have already explained that you don't want to do this, though, so I only mention it in passing. (Also, even when used, this should not be relied upon. Clients don't have to execute JavaScript. Even if they did, one could hack up one's client to do whatever one pleases. The server-side processing would still be necessary for actual verification purposes; the client-side processing is merely a convenience to avoid unnecessary page reloads.)

BTW, I should point out that I have no objection whatsoever to sending javascript to the browser. The problem is, there is no way to do that without erasing the current page. At least, that's what MY tests show. Does anyone have different results? If so, how did you do it?

Another way is to have javascript open a new window (window.open) that calls out to your perl script which displays the html for a prompt and talks to the parent via javascript. Can also be annoying, but in general I have used it without real problems.

Yet another way (probably) is to use dhtml to pop up something. I have only played with dhtml a little, but I am guessing you should be able to build a prompt window that is hidden, and have it pop up and do its thing when you click the right button.

All of these use javascript to some level, usually what I will do is us javascript to copy whatever they type in back to a hidden form field, then submit the form... not overly difficult.

> Unless I'm understanding the question wrong, it seems like you want to a call to a CGI script to return with just a pop-up alert and not affect the actual page it was called from.

You got it. And yes, it does seem that it isn't possible without intervening javascript before going to the cgi code. For doing simple forms, that's not so bad. But when you don't know whether data in a form isn't right until you've gone to the server side (which may require doing db searches, etc.), you're basically forced to redraw the page... and that may also be an equally expensive operation.

Ah, ok, now I kinda get what you want. But what about a simple something like this?

print header;
print <<EOF
<script language="JavaScript">
alert('Hello World');  
history.go(-1);
</script>
EOF
;
[download]

This way, you will get your popup and the user will go straight back to the previous page which probably is still cached (if JavaScript is turned on ... of course). For simple forms, this should be ok.

--
b10m

You got it. And yes, it does seem that it isn't possible without intervening javascript before going to the cgi code. For doing simple forms, that's not so bad. But when you don't know whether data in a form isn't right until you've gone to the server side (which may require doing db searches, etc.), you're basically forced to redraw the page... and that may also be an equally expensive operation.

This is exactly why people use javascript to do client side data validation. It's an extremely common practice to have a bit of javascript triggered before you actually send the datato make sure it's all in the right format. Done correctly theres absolutely no server side work and no communication or time.

But of course you can't trust the client to validate correctly. Never trust the client. You still have to validate server side.