First of all, what you are doing is Cargo Cult programming. Granted, a lot of us started that way, and some of us fall into that trap each time we meet an unfamiliar language/system/environment, but it leads to high blood pressure and hair loss. You should first try to understand WHY something is written the way it is, and only then try to write your own.
I don't know where you picked the "supposedly standard format", but it wouldn't run in any JavaScript I ever came across. I don't even see the purpose of doing it that way: after all, if you want to display a form with empty fields, just print it that way.
But in the hope that it might do some good to you and others who might run across this article, let me write something about setting fields in HTML forms in general.
There are several options:
- You can hardcode your values into your HTML file (<input type=text name=whatever value="hello world!">), and simply send that to the browser with a single print statement.
- You can laboriously construct the form inside your CGI script, either by using <<here documents, or by using CGI.pm's HTML element routines (print textfield(-name=>'whatever' -default=>'hello world!');
- You can use a templating tool, such as HTML::Template, let a designer design the HTML, and then change each input field to have something like this:<input type=text name=whatever value="<TMPL_VAR name="whatever">">. Once you've done that, you can set all the values from your script very quickly.
- Or (recommended for applications you're likely to come accross in the near future), you could use HTML::FillInForm, which parses the HTML on the fly, and then lets you assign all the values very quickly and conveniently.
None of that options can be said to be Best option for all occasions. Each option involves compromises. The easier it is to implement, the slower it will likely be once it is deployed. But even HTML::FillInForm, which parses the HTML each time it displays it, is plenty fast for most applications.
And hopefully, by the time you graduate to writing scripts that need to run on a hundred-requests-per-second production server, you will have developed a feeling of when programmer convenience needs to be sacrificed to the goods of speed, and when programmer's time is better spent doing other things. | [reply]
[d/l]
[select] |
If you are using CGI.pm, it has the feature of "sticky fields", that is, fields that retain their value on output. This is in most cases a very welcome addition as the user dosen't have to type in information again just because the CGI script didn't accept the data as a whole.
To switch off this very convenient behaviour, you can use :
use CGI qw(:standard -nosticky);
or if you want to replace a single form field value with another value from your script, the CGI.pm documentation tells you the following way:
$query->param('field_name','new value');
| [reply]
[d/l]
[select] |
I think this is a typical "I want to ask $a, but do so by first asking $b, then complain and ask $a afterall", for I have given your post some thought and cannot think of any useful reason to reset a form when a user submits it.
If I get this right, you want the user to fill out a couple of form elements. After (s)he filled that out and presses the submit button, you want to clear all input and submit empty fields to your CGI script? Why offer a form? Why not call the script directly?
Personally I hate reset buttons/functions because I always hit them by accident, resulting in typing the input twice (usually I pay more attention to what button to press the second time around ;) If I mistakenly filled out a form, I'll delete it myself, or just leave the site, but all this is besides the point.
The point/question is: what do you really want with your form?
--
b10m
All code is usually tested, but rarely trusted.
| [reply] |
First off I apologize for my ignorance, it probably's stinking up the halls of the temple but here it goes...
(You're right b10m I was a little vague and this is $a afterall)
The problem is this:
I have a script a.cgi in which I have a form that submits the name of a text field to another script, b.cgi. Then b.cgi uses this name (does something) and returns it back to a.cgi (via a hidden field) to display this name in the some html generated by a.cgi after it returns from b.cgi.
(This is for a forum. The main page (a.cgi) contains a request for new thread in the form of a text box. Once a name for a new thread is entered, you are taken to the writting page (b.cgi). Then you're redirected back to a.cgi to display the name of the posting as a n html link to the actual post (a text page generated in the previous page) )
The problem is that a single post has been posted and I'm back in a.cgi looking at the hyperlink, if I press reload, another identical last thread link appears. This is because the a.cgi form that first forwarded the name is retaining its last entered value and creating a form everytime a.cgi is refreshed. (I dont mind that the form that creates a new thread is run everytime the page is refreshed since I have a check that doesn't write the thread if the name entered is less than four characters in length such that when a new form tries to be generated with a blank name it is ignored)
I actually got the forum going by making it only display the forum link in a.cgi if the last page was b.cgi (the page in which the form is written) and the form name is not in the log file that contains all of the thread names. However, I shouldn't need the first check. How can I get a fresh form everytime the page is refreshed without using these checks?
| [reply] |
# OO way
$q->delete_all();
# other, just
delete_all();
The question is then "How do I clear CGI parameters on processing a submitted form?".
Of course, that may not be the question. For future reference, I suggest you post code samples when asking questions, especially when you're unsure exactly what it is that you are asking.
.02
cLive ;-)
ps - if you are looking at JavaScript, there a snippet in my article on http headers here, | [reply]
[d/l] |
Do you have a Perl question? Your question is kind of vague,
but it looks more about JavaScript than any other computer
language.
Abigail | [reply] |