views:

45

answers:

4

Hi. Please consider the following HTML:

<input type='text' id='name'/>
<option id='option'>
  <select value='1'>hi</select>
  <select value='2'>bye</select>
</option>
<input type='text' id='date'/>

This is a very simple form used to get search criteria from a user. I need to submit this search criteria to the server with an AJAX call. What is the best data type/structure to use to do this? And why?

I'm currently thinking a string vs. JSON object. So, I'll either pass

"John|2|2010-10-10" 

to the server or I'll pass

{"name":"John","option":2,"date":"2010-10-10"}

Maybe there is some other creative way to deal with search criteria? This criteria is being shot to the server only one time, it doesn't come back to js.

Thanks.

A: 

Use the jQuery form plugin

http://jquery.malsup.com/form/

Jerome
redsquare
How is this better then JSON object or a string? It's a small piece of data that is being used 1 time in 1 place. What's the advantage of including a whole new plugin when (to my mind) this is something small and simple? Thanks!
Dimskiy
A: 

It's always best to create an own data structure to transport data. You can design the format 100% the way you need and expect it to be, so it's small, fast and therefore efficient.

The second best option is JSON, which is already pretty lightweight and fast. But again, no format beats your own.

The downsite of this is obvious, it's not compatible nor portable. So you have to take that into consideration.

jAndy
Could you tell more about "own data structure"? Shouldn't it still be in a JSON notation? Or how would it differ from JSON?
Dimskiy
@Dimskiy: you made the perfect example already. `"John|2|2010-10-10"` is very precise with a minimum of structur. It's adapted to what you need and what you expect. The same structure as JSON has much more data in comparison. So when data grows, that impact will grow aswell.
jAndy
@jAndy: If I understood you correctly, given JSON vs. "val1|val2|val3", you would suggest going with "val1|val2|val3"?
Dimskiy
@Dimskiy: Not exactly. I was just trying to say that your "own" data structure is always better in performance (if you do it well, but I just assume that) than any "static blackbox" data format. But as I mentioned, it also has it's downsites in terms of portability and compatiblity. But you if have the effort to write your own little encode/decode functions (which is trivial in a well defined environment) and you need as much performance as you can get (data size), you should do it.
jAndy
One thing to consider is whether anyone but you will be working on this project, or whether you may have to come back and maintain this project after some time away. Right now it may be clear in your mind that if you get "val1|val2|val3" it means search text|option|date, but someone else may not know that, and you may forget it. I like self-documenting formats.
JacobM
+1  A: 

Google uses querystrings, the equivalent of:

search?name=John&option=2&date=2010-10-10

This has a few advantages:

  • searches can be bookmarked or emailed as links
  • its appropriate that a search is a GET request rather than a POST, since it doesn't change the state on the server
  • it gives you an easy "poor man's API" whereby a request to perform a particular search can be generated very simply

disadvantages:

  • you have to URL-encode everything
  • search strings get archived in logs, etc.

That said, if you're choosing between the options you gave, I would choose JSON: it's a bit longer, but I think it will save you a lot of headaches to have explicitly named parameters (rather than relying on location within a string).

JacobM
Thank you! I see where you coming from. However, I'll pass on the idea of urls for various reasons unrelated to this question.
Dimskiy
+1  A: 

If you wrap your HTML in a <form> tag, you can easily use the $.serializeArray() function in jQuery.

http://api.jquery.com/serializeArray/

$.serializeArray() creates a JavaScript object literal in the form of:

[ {name: a, value:1}, {name: b, value: 2}, ...]

This is done, I believe, because your form could have multiple fields with the same name. An associative array wouldn't support this.

I'd recommend that you send your data to your server in a JSON format (using serializeArray or some other method) rather than a plain string. JSON is more standardized and can handle escaping characters. If you're using pipe-delimited strings, then you have to take into account when a user wants to submit a pipe (|) to the server. Then you get into situations where you have crazy delimiters like ||** between values. (I've seen this -- it's ugly!). Stick with JSON.

If you'd prefer a more querystring-like format (e.g. a=1&b=2&c=3) that you can include in your request body, you can use $.serialize().

http://api.jquery.com/serialize/

David Hoerster
I did not know about this function. I'm going to play around with it a little.
Dimskiy
Ok, so I played around with this function. I love how easy it is to get elements from a form, even if the form has over 100 elements on it. What I don't like, is that it creates an array of key-value pairs. I don't see an easy way to retrieve a value from such an array: jsonObj['date'] would be equivalent of thisObj[index]['value'], where I don't know what index is until I manually find it with key 'date'.
Dimskiy
I believe it hands you the data this way, instead of an associative array, because you could have form elements with the same name. This wouldn't work with an associative array. If you want to pass data in the request body in a querystring-like format, you can use `serialize()` instead. I've updated my answer with this info.
David Hoerster
I'm choosing this answer and here is why. This way, if the data is changed in DB and the form on UI is changed accordingly, I don't have to make any changes to the actual JavaScript that handles this AJAX call. Also, if the output of $.serializeArray() isn't 100% what is needed, you could always run a quick foreach loop to get the data in the desired format.
Dimskiy