Help - A HREF="#" - Difference between NS/IE and Mozilloids

[Cranio]

Hi!

I have an ASP-generated code that spits out a form.

This form contains links like:

<A HREF="#" onClick=".......;submit()">

My goal is to force a Form submit, thereby passing
also the QueryString values.

In IE and Netscape it works fine.. Firefox though
doesn't do anything! The link is "clickable" but
dead...

How can I work through this problem? I am writing
a Content Management Systems and I'd like it to be
cross-browser compatible...

Tnx in advance

 

[David Dorward]

I have an ASP-generated code that spits out a form.

This form contains links like:

<A HREF="#"

Don't do that.

'<a href="something.html" onclick="somefunction();
return false"> where something.html is meaningful
to the non-javascript capable'
-- http://jibbering.com/faq/#FAQ4_24

onClick=".......;submit()">

So it does something, then it calls a function called submit(). It obviously
isn't calling the submit method of the form, and there isn't such an
internal function, so it must be defined elsewhere in your code. (And as I
can't see it ...)

My goal is to force a Form submit, thereby passing
also the QueryString values.

Use a submit button then. You can always style it as a link if you really
want to, but things that look like links say "visit a page" to the user,
things that look like submit buttons say "send this form data somewhere",
so it probably isn't a very good idea.

In IE and Netscape it works fine..

Netscape 4.x?
Netscape 6+? (Which IS Mozilla with minor modifications)
Netscape 8? In Firefox mode or Internet Explorer mode?

Firefox though doesn't do anything!

What about Opera and Safari/Konqueror?

 

[Cranio]

Cranio wrote:


Don't do that.

Had some suspects I shouldn't

'<a href="something.html" onclick="somefunction();
return false"> where something.html is meaningful
to the non-javascript capable'
So it does something, then it calls a function called submit(). It obviously
isn't calling the submit method of the form, and there isn't such an
internal function, so it must be defined elsewhere in your code. (And as I
can't see it ...)

Wait.. maybe the submit() button is "loose", if you forgive my bad
English and my bad explanations

But I've tried to force the submit() also as a method of the form with

document.getElementById("formname").submit() or
document.getElementById("submitbuttoname").submit()...

still nothing

Use a submit button then. You can always style it as a link if you really
want to, but things that look like links say "visit a page" to the user,
things that look like submit buttons say "send this form data somewhere",
so it probably isn't a very good idea.

It's better to explain...

I have this database table admin page... every row of the table has a
clickable link to select it, passing the primary key ID via querystring
to the SAME page... If this ID is not undefined, the page will also
display a form to change the field values and update the DBso the
HREF="#" will REFRESH the page in IE and NS,
passing this data.

Is there a more proper method to accomplish this?

In IE and Netscape it works fine..

Netscape 4.x? [...]
What about Opera and Safari/Konqueror?

You are right... my tests for now are very limited... but I'm on the
path of Learning

 

[Cranio]

Cranio wrote:

[...]

Wait.. maybe the submit() button is "loose", if you forgive my bad

Oww... sorry, meant submit FUNCTION... I really meant that maybe
IE and NS Javascript engines are forgiving, and will submit also
if the object calling the submit() function isn't properly a button
or form

 

[Mitja]

I have this database table admin page... every row of the table has a

clickable link to select it, passing the primary key ID via querystring
to the SAME page... If this ID is not undefined, the page will also
display a form to change the field values and update the DBso the
HREF="#" will REFRESH the page in IE and NS,
passing this data.

Hmm... not 100% I got you right, but would this do?

<tr>
<td>1</td>
<td><a href="show.asp?primaryid=1">First row</a></td>
<td>Some property of the first row</td>
<td>And some more info</td>
</tr>
<tr>
<td>2</td>
<td><a href="show.asp?primaryid=1">Second row</a></td>
<td>Some property of the second row</td>
<td>And some more info</td>
</tr>
<tr>
<td>3</td>
<td><a href="show.asp?primaryid=1">Third row</a></td>
<td>Some property of the third row</td>
<td>And some more info</td>
</tr>

You probably don't need javascript, the page show.asp should generate code
like above that links to itself with various (server-side-)precomputed
parameters.

 

[Cranio]

You probably don't need javascript, the page show.asp should generate
code like above that links to itself with various
(server-side-)precomputed parameters.

That's right... I just wrote 1 min ago a workaround that builds links like

"<A HREF='" + Request.ServerVariables("URL") + "?" + pk + "=" + pkvalue
+ "'" ... +"</a>

Works for GET ... but what about POST data?

 

[Mitja]

"<A HREF='" + Request.ServerVariables("URL") + "?" + pk + "=" + pkvalue
+ "'" ... +"</a>

Works for GET ... but what about POST data?

Yep, POST is a problem with no easy solution. Sometimes the easiest thing
to do is to change the architecture of your program in such a way that it
only need GET (or at least only need GET in situations where links like
the one above are desired). This is not as hard as it seems: the only
thing at which POST is better is sending large chunks of data, and where
do you objectively have to send large chunks of data with a single link
and no elements with user-input data?
Alternatively, you can provide a button instead of a link to get the POST
functionality, but you know that.
Or you can keep trying with JS, but I'm afraid I am no expert at that. I
thought what David provided worked - have you tried it?

 

[David Dorward]

the only thing at which POST is better is sending large chunks of data,

Not true. It's also rather better at saying "This is going to change
something on the server. If the user hits follows a link from the target
place and then hits back, or if they hit refresh, then shove a dirty great
warning in their face, oh, and don't go precaching the content - you'll
check stuff on the server that the user might not want to change!"

 

[Cranio]

Yep, POST is a problem with no easy solution. Sometimes the easiest
thing to do is to change the architecture of your program in such a way
that it only need GET (or at least only need GET in situations where

Right. It's precisely what I am doing now, and luckily my program is
flexible enough )

links like the one above are desired). This is not as hard as it seems:
the only thing at which POST is better is sending large chunks of data,
and where do you objectively have to send large chunks of data with a
single link and no elements with user-input data?

All right BUT it would be nice for me to find a REAL solution to the
problem, say for knowledge's sake

 

[Jonathan N. Little]

Right. It's precisely what I am doing now, and luckily my program is
flexible enough )



All right BUT it would be nice for me to find a REAL solution to the
problem, say for knowledge's sake

Just a thought, if you are trying to post data, you do have the form
elements WITHIN <form></form> tags, right? I have seen some folks try to
summit form data with either no form, or with form data elements outside
of the form tags. Firefox will not forgive these errors and will not
work. Some other browsers may confuse the situation by working on
'ASSUMPTIONS'!

 

[Cranio]

Just a thought, if you are trying to post data, you do have the form
elements WITHIN <form></form> tags, right? I have seen some folks try to
summit form data with either no form, or with form data elements outside
of the form tags. Firefox will not forgive these errors and will not
work. Some other browsers may confuse the situation by working on
'ASSUMPTIONS'!

That's right, but my links were absolutely WITHIN a form

 

[Joel Shepherd]

the only thing at which POST is better is sending large chunks of data

No. POST and GET have entirely different semantics, beyond how the query
data is sent to the server.

http://www.cs.tut.fi/~jkorpela/forms/methods.html

If submitting the form is expected to result in some important change of
state on the server side (e.g., an order being placed, form data being
saved in a database, someone's pager going off), then POST should be
used.

In addition, responses to "GET" requests can be cached (by the browser,
by a proxy, etc.), while "POST" responses generally are not.

This is probably relevant to the OP, since it sounds like 'Cranio' is
expecting users to click on the link to refresh their view of table
data. If that's the case, then "GET" is not appropriate, as the browser
may simply display the results of an earlier GET, and not fetch the
current row data from the database.

I don't know if it's still the case, but at one time this was actually a
defect on the Amazon site: you could add an item to your cart, hit a
"View Cart" link (a GET), see the item there, add another item to your
cart, hit "View Cart" again, and still see only the first item added to
the cart. The first "View Cart" response had been cached and redisplayed
the second time around, even though the state on the server had changed
since. Oops.

 

[Mitja]

No. POST and GET have entirely different semantics, beyond how the query
data is sent to the server.

http://www.cs.tut.fi/~jkorpela/forms/methods.html

True, I missed that - the implied semantics are indeed quite different.
But - see below. I was perhaps a bit too practical and thinking too much
along the lines of OP's specific case:

If submitting the form is expected to result in some important change of
state on the server side (e.g., an order being placed, form data being
saved in a database, someone's pager going off), then POST should be
used.

OP's description hardly satisfies this criteria.

In addition, responses to "GET" requests can be cached (by the browser,
by a proxy, etc.), while "POST" responses generally are not.

True, and I feel this is the main point I should have mentioned. It can,
however, be circumvented by using appropriate headers. And, honestly -
would you ever implement a plain-text link as a combination of POST and an
invisible form just to try enforcing a clean reload? I still feel GET is
more appropriate in the given scenario (if I got its description right).

 

[Joel Shepherd]

would you ever implement a plain-text link as a combination of POST and an
invisible form just to try enforcing a clean reload?

No. If a clean reload was the requirement, I would use a proper button
and form to do a POST. I can worry about styling the button to make it
prettier, later. But I think it's generally better to get the
functionality right and then worry about polish and performance (not
that that's an issue here), than to get things all pretty-like and then
worry about actually making them work.

I still feel GET is
more appropriate in the given scenario (if I got its description right).

Yeah, the problem description is a shade ambiguous.