www.webdeveloper.com
Results 1 to 14 of 14

Thread: How can I get query string values?

  1. #1

    How can I get query string values?

    Is there a plugin-less way of retrieving query string values via jQuery (or without)?

    If so, how, and if not what plugin do you recommend?

  2. #2
    Join Date
    Jan 2010
    Posts
    77
    Hi bud

    It is fairly easy to get the querystring by just using javascript, if you could expand on why you need to do this it might help us give you a more relevant answer.

    This script will strip the querystring and then split the name value pairs out and display them to the page.
    Code:
    <html>
      <head>
         <script type="text/javascript">
           function getQuerystring(){
             var q=document.location.toString();
             q=q.split("?");
             q=q[1].split("&");
             var str=""
             for(i=0;i<q.length;i++){
               tmp=q[i].split("=")
               str+=i +". querystring name is '"+tmp[0]+"' value is '"+tmp[1]+"'<br />"
                                              }
             document.getElementById("results").innerHTML=str
                          }
        onload=function(){
               getQuerystring()
                         }
         </script>
      </head>
      <body>
        <div id="results"></div>
      </body>
    </html>
    V

  3. #3
    Join Date
    Oct 2010
    Location
    Versailles, France
    Posts
    1,266
    The property search (document.location.search) gives immediately the query portion of a URL(with the ? character). See location object

  4. #4
    Join Date
    Jan 2010
    Posts
    77
    Quote Originally Posted by 007Julien View Post
    The property search (document.location.search) gives immediately the query portion of a URL(with the ? character). See location object
    That is interesting Julien, I didn’t know that

    One thing that confuses me with these kind of requests regarding getting the name value pairs out of a querystring client side, is that presumably since it is your script, in your page, you already have that information server side, which kind of negates needing strip it out of the url client side in the first place.

    Or am I missing something, is there a condition where this would be useful?

    V

  5. #5
    Join Date
    Oct 2010
    Location
    Versailles, France
    Posts
    1,266
    It's a possibility to transfer data between two pages with or without server...

  6. #6
    Join Date
    Jul 2008
    Location
    urbana, il
    Posts
    2,787
    it can be useful for more than just passing data without a server, which is better done using localStrorage for size reasons.

    many times, you might want to style a section differently depending on some GET param. Or you may want to build links to other functionality based upon what is happening right now.
    while GET info is used by the server, it's often easier to deliver scripts as a bundle and let them sort themselves out without help from the server. this could mean, for example, loading an additional validation lib when a form page is offered, or a gallery script if a slideshow is presented.

    there's also applications for custom error messages based on failed GET form submits, and the potential to use a querystring to store the application's state. This lets the back button change app state all at once, but requires javascript to decode and apply all those settings once the page url changes.

    in short, there a lot the server can't do, especially without internet, but GET params are a common way to store and share small chunks of data independently of the domain, application, or server implementation.

  7. #7
    Join Date
    Jan 2010
    Posts
    77
    Hi rnd me
    Sorry bud, but I just donít buy it

    Quote Originally Posted by rnd me View Post
    it's often easier to deliver scripts as a bundle and let them sort themselves out without help from the server. this could mean, for example, loading an additional validation lib when a form page is offered, or a gallery script if a slideshow is presented.
    That seems like a really bad idea, bundling scripts and letting them sort it out with the querystring, that sounds like a recipe for disaster to me, and a lot more work. Personally I would just make the page and the scripts that go with it and send them at the same time or make a library and send it to all the pages if I was going to use the scripts in all the pages, but this negates your point.

    Quote Originally Posted by rnd me View Post
    there's also applications for custom error messages based on failed GET form submits,
    If you are using GET to submit a form (which I donít do) and it fails then you are still server side so you can send whatever error message you want, again it seems rather pointless to write a script to do what the server can do in a heartbeat.

    Quote Originally Posted by rnd me View Post
    and the potential to use a querystring to store the application's state. This lets the back button change app state all at once,
    Since the web is, to all intents and purposes is a stateless environment, with the exception of session variables which are, as I am sure you know, kept on the server. You cannot keep with any degree of accuracy, your applications state using the querystring. The sad fact is that kind of coding would leave you wide open to someone hacking your app

    Quote Originally Posted by rnd me View Post
    in short, there a lot the server can't do, especially without internet,
    err..... well there is nothing a server can do without the internet it seems rather silly to have to point that out

    Quote Originally Posted by rnd me View Post
    but GET params are a common way to store and share small chunks of data independently of the domain, application, or server implementation.
    Again I donít buy it, if you wanted to keep small chunks of data then use a cookie since that was what they were designed for in the first place.

    I am still fairly sure that there are several better ways of doing all of what you have mentioned, you have even alluded to one yourself (HTML5ís localstorage), and are to my mind at least, far more secure that stripping out the name value pairs from the querystring, it is just far to visible to the user and far too easy to be manipulated

    In short I remain unconvinced that this is a good approach, or even useful.

    V

  8. #8
    Join Date
    Oct 2010
    Location
    Versailles, France
    Posts
    1,266
    A simple example : to retrieve a post on a page, it could be useful to send and return the scroll height in a query string...

  9. #9
    Join Date
    Jul 2008
    Location
    urbana, il
    Posts
    2,787
    Quote Originally Posted by Vince616 View Post
    Hi rnd me
    Sorry bud, but I just don’t buy it
    In short I remain unconvinced that this is a good approach, or even useful.
    V
    i never said any of the examples were the best or even a good approach, i was simply trying to give you some basis for what this sort of functionality MIGHT be used for in the wild.
    that said, what's up with the multiquote refutation, kinda rude...


    The fact the JS doesn't ship with the parser is a good indication that it's not the go-to IO paradigm for 21st century computing.

    a lot of app don't have or need a server, but they still want outside linking, and this is one obvious way of doing so.
    personally, i like location.hash better, since it doesn't go over the wire, but it both let you create incoming links the prep the display or pre-fill some data in the app.

    if you have a blank slate in front of you, then yes, there are better approaches to each of the examples i mentioned.
    often times, we don't control what we're handed, we just have to make it work.
    it would be nice if every useful querystring value were poked into html in some semantic fashion, but that's not always the case.
    Last edited by rnd me; 04-22-2013 at 06:25 PM.

  10. #10
    Join Date
    Jan 2010
    Posts
    77
    I am terribly sorry that I have managed to offended you rnd me, that was not my intention, I just saw holes in your argument and thought that it was worth replying to them in a logical and systematic manner which involved, as you put it a “multiquote refutation”, I will from this point on refrain from refuting your arguments

  11. #11
    Join Date
    Jan 2010
    Posts
    77
    Quote Originally Posted by 007Julien View Post
    A simple example : to retrieve a post on a page, it could be useful to send and return the scroll height in a query string...
    I see your point, but, lets say you append the querystring of some forum page with something like “&sh=464” to give you the value of the scroll height, if you want to retrieve that value client side you will need to write a function to parse it out of the querystring then write another function to scroll the page to the value: whereas if you were to do it server side all you would need to do is write the one function to scroll the page and add the value server side, surely that is far easier.

  12. #12
    Join Date
    Jul 2008
    Location
    urbana, il
    Posts
    2,787
    Quote Originally Posted by Vince616 View Post
    I see your point, but, lets say you append the querystring of some forum page with something like “&sh=464” to give you the value of the scroll height, if you want to retrieve that value client side you will need to write a function to parse it out of the querystring then write another function to scroll the page to the value: whereas if you were to do it server side all you would need to do is write the one function to scroll the page and add the value server side, surely that is far easier.
    actually it's more complicated to do it like that, correctly at least. Typically data, view and content are separated, which means javascript should be served from external files instead of inline scripts. This means you shouldn't tuck the scroll amount into the html view, which means it comes from a 2nd url. for most web systems like lamp and asp, that adds additional complexity. and ok, so you separate the state from the html view, that good, but how to you get the scroll amount to the client on an external url? then you have to use ajax or create a callback to use jsonp. that's a lot more complicated than 1 drop-in function and 1 custom line of js.

    i don't get why anyone would want to use a server for something that can be done on the client. it's not 1995 anymore.
    it's quicker for a million folks to parse their own params than for your server to parse them all.
    think about parallel processing versus serial processing, and which is faster...
    let them do the work for free and use your server CPU cycles where it counts.

  13. #13
    Join Date
    Jan 2010
    Posts
    77
    Hi rnd me,
    As I mentioned before I will refrain from refuting your arguments, as I have neither the time, nor the desire to upset you.

    Let us agree to disagree and leave it at that.

  14. #14
    Join Date
    Jul 2008
    Location
    urbana, il
    Posts
    2,787
    Quote Originally Posted by Vince616 View Post
    Hi rnd me,
    As I mentioned before I will refrain from refuting your arguments, as I have neither the time, nor the desire to upset you.

    Let us agree to disagree and leave it at that.
    i;m glad you see the light, who needs that dusty old server anyway?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles