If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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?

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.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

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.

Originally Posted by rnd me

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.

Originally Posted by rnd me

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

Originally Posted by rnd me

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

Originally Posted by rnd me

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.

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 07:25 PM.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

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

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.

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.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com