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

Discussion in 'HTML' started by Cranio, Jun 18, 2005.

  1. Cranio

    Cranio Guest

    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
    Cranio, Jun 18, 2005
    #1
    1. Advertising

  2. Cranio wrote:

    > 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?


    --
    David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
    Home is where the ~/.bashrc is
    David Dorward, Jun 18, 2005
    #2
    1. Advertising

  3. Cranio

    Cranio Guest

    David Dorward wrote:
    > Cranio wrote:
    >
    >
    >>I have an ASP-generated code that spits out a form.
    >>
    >>This form contains links like:
    >>
    >><A HREF="#"

    > 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'
    >>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 ...)


    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

    >>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.


    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, Jun 18, 2005
    #3
  4. Cranio

    Cranio Guest

    Cranio wrote:
    > David Dorward wrote:
    >
    >> 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
    Cranio, Jun 18, 2005
    #4
  5. Cranio

    Mitja Guest

    > 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.
    Mitja, Jun 18, 2005
    #5
  6. Cranio

    Cranio Guest

    Mitja wrote:
    >> 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.


    > 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?
    Cranio, Jun 18, 2005
    #6
  7. Cranio

    Mitja Guest

    On Sat, 18 Jun 2005 11:57:27 +0200, Cranio <> wrote:

    > "<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?
    Mitja, Jun 18, 2005
    #7
  8. Mitja wrote:

    > 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!"

    --
    David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
    Home is where the ~/.bashrc is
    David Dorward, Jun 18, 2005
    #8
  9. Cranio

    Cranio Guest

    Mitja wrote:
    > On Sat, 18 Jun 2005 11:57:27 +0200, Cranio <> wrote:
    >
    >> "<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


    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 :)
    Cranio, Jun 18, 2005
    #9
  10. Cranio wrote:
    > Mitja wrote:
    >
    >> On Sat, 18 Jun 2005 11:57:27 +0200, Cranio <>
    >> wrote:
    >>
    >>> "<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

    >
    >
    > 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 :)

    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'!

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jun 18, 2005
    #10
  11. Cranio

    Cranio Guest

    Jonathan N. Little wrote:
    > Cranio wrote:
    >
    >> Mitja wrote:

    > 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 :)
    Cranio, Jun 18, 2005
    #11
  12. In article <op.sskd3ipqdob4us@ibis>, Mitja <> wrote:

    > 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.

    --
    Joel.
    Joel Shepherd, Jun 18, 2005
    #12
  13. Cranio

    Mitja Guest

    On Sat, 18 Jun 2005 20:03:02 +0200, Joel Shepherd <>
    wrote:

    > In article <op.sskd3ipqdob4us@ibis>, Mitja <> wrote:
    >
    >> 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


    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).
    Mitja, Jun 18, 2005
    #13
  14. In article <op.sskw1secdob4us@ibis>, Mitja <> wrote:

    > 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.

    --
    Joel.
    Joel Shepherd, Jun 19, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jakk
    Replies:
    4
    Views:
    12,138
  2. =?Utf-8?B?U2FyaXRhIFNhaSBCaHVzaGFu?=

    difference between location.href & Autopostback in active desktop

    =?Utf-8?B?U2FyaXRhIFNhaSBCaHVzaGFu?=, Feb 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    633
    =?Utf-8?B?U2FyaXRhIFNhaSBCaHVzaGFu?=
    Mar 7, 2006
  3. Bernd Oninger
    Replies:
    1
    Views:
    524
    Henry S. Thompson
    Jun 30, 2004
  4. saiho.yuen
    Replies:
    3
    Views:
    421
    kaeli
    Sep 14, 2004
  5. Replies:
    2
    Views:
    462
Loading...

Share This Page