views:

112

answers:

6

Hi everyone,

I am very new to Javascript and Jquery, so my apologies for this beginner's question.

In a simple ajax web app, I am creating an HTML page which is mainly a big table. Each row in this table describes an event (party, show, etc). My page not only displays this information but is meant to let the user do a bunch of things with it, in particular to dynamically search and filter the table according to a variety of criteria.

First an abstract beginner's question: in this broad kind of situation (by which I mean that you want your javascript code to run a bunch of operations on the information you retrieve from the webserver) would you use the DOM as a data structure? The ease with which one can search and manipulate it (using Jquery) makes that a possibility. (E.g., "find me table rows describing an event with date column = 2010-01-01 and event type column = 'private party'.) Or would you keep the same information in a traditional Javascript data structure, search/filter/operate on that using plain javascript code and then update the DOM accordingly to display the results to the user?

(As a newbie, I imagine the first, DOM-only approach to be slower while the latter to be take up a good deal of memory. Right? Wrong?)

Assuming the second strategy is reasonable (is it?), then a practical question: can I simply store in my Javascript objects a pointer to the corresponding Jquery object? Eg, can I do

var events = new Array();
// ....
var event3094 = new Event('party','2010-01-01' /*, ... */);
event3094.domElement = $("#correctIdOfTheEventRowInMyTable");

events.push(event3094)

Does this store just a reference (pointer?) to the Jquery object in each Event object or is it creating a new copy of the Jquery object?

I am just wondering "how the pros" do it. : )

Thank you for any advice and insight.

cheers

lara

A: 

I think you'l find that the DOM method is close to the same speed if I follow your logic right. The second method will require you to manipulate the data, and then apply the changes to the DOM, where the first method allows both operations at the same time.

highphilosopher
A: 

I think it's largely a personal preference, but I like to store the objects in JavaScript and then render them to HTML as needed. From my understanding

event3094.domElement = $("#correctIdOfTheEventRowInMyTable");

will store a reference to the jQuery wrapper of your row element (not a copy).

One benefit of storing is JS is that if you have lost of objects (eg 10,000 ) and only render a small fraction of them, the browser will perform a lot better if you're not creating 10,000 * (number of DOM elements per object) elements.

Edit: Oh, and if you can, you might want to send the data from the server to the client as JSON. It's very compact (compared to XML) and in the new browsers it can be parsed quickly and safely using JSON.parse(). For older browsers, just use this library http://www.json.org/js.html . The library will only create a global JSON namespace if the browser doesn't supply it.

Nogwater
+1 for JSON. You don't even need to mess with AJAX calls, just embed the JSON data directly in the page. Something like (using php):<script> var myinput = JSON.parse("<?php echo json_encode($mydata) ?>");</script>
MadCoder
This is true but to my knowledge you dont get the ease of traversal using json... dont you then have to attache methods or write functios to do the traversal for you? My point with XMl was that youve already got built in traversal/manipulation methods.
prodigitalson
prodigitalson is correct; while JSON is incredibly compact and might very well be the most ideal solution in many cases, you don't get the already-provided functionality that you get with jquery + XML/DOM to run the kind of searches/filters that the original poster mentioned...
Funka
A: 

If youve got alot of data i would for go making objects and just supply it as XML. that way you get most of the same features as operating on the HTML DOM but you dont have a crazy markup structure like a table to navigate through.

prodigitalson
+4  A: 

There are so many ways to do this, but DOM manipulation will almost always be slower than JS manipulation.

To answer your question, anytime you use $(selector) a new jQuery object is created and a match to find the element is performed.

I would recommend two approaches:

FIRST OPTION

  1. Load data in a normal HTML table
  2. Read through the rows, and store just the data (each cell's contents) in an array similar to your code example.
  3. Store a reference to the tr in that object.
  4. Then you can process filter, etc, and only apply changes and searches to the DOM as needed.

SECOND OPTION

  1. Load the page without the table
  2. Load the data as JSON from the server, and generate a table from the data
  3. Store reference to the tr element

Basically, you don't want to perform a $(selector) a 1000 times. The concept is something like this:

var $rows = $("table tr");

// ...

event.domElement = $rows[0]; // Stores reference to existing DOM node, not a new jQuery object.

Then when you need to use jQuery methods on the object, you could use $(yourEvent.domElement) to wrap it in a jQuery wrapper.

Doug Neiner
Thank you, that was very helpful! Just to clarify one thing: if I know I will eventually be manipulating the DOM elements using jquery functions, should I still store just a reference to the DOM element in my event object (and then use $(event.domElement) to wrap it into a jquery object) or should I store the Jquery object itself from the beginning? thanks!
laramichaels
I would say wait. I am guessing it is unlikely that they will be editing all 50+ rows every time they are on the page. If you plan on touching all rows one at a time during every session, then yes, store the jQuery object.
Doug Neiner
A: 

One thing to consider is how you need to access your data. If all the data for an element's event is contained in the element (an event operating solely on a table cell for example), then storing in the DOM makes sense.

However, if the calculation of one element depends on data form other elements (a summation of all table cells in a particular column, for example), you may find it difficult to gather up all the data if it's scattered about in DOM elements compared to a single data structure.

MadCoder
+2  A: 

Depending on the number of rows you might expect to be shown for most of your users (let's assume it's no more than a few hundred), I myself would probably aim to just keep everything in the DOM table that you're already building. (If you are expecting to be dealing with thousands of rows on one page, you might want to explore a different solution rather than sending it all to the browser.)

There are a few things that you did not mention in your original post. First, how are you creating this table? I imagine using a server-side solution. How easy is that to modify? How much extra work would it be to go through and generate all of your data a second time in a different format, as XML or JSON? Does this add a bunch of complexity on the server-side, only so that you can add more complexity client-side to match? Certain platforms may make this trivial, but is something to consider.

Now, in regards to your alternatives to the DOM:

I agreed and mentioned in a comment above that I don't think JSON would be very optimal "out of the box" for what you want to do. A javascript array is no better. XML is nice in that you can use jquery to easily traverse/filter, but then you still have to deal with your DOM. Sure, you can store references to your DOM elements, but that just seems like a bunch of work up front and then some more work later when matching them up. And without necessarily guaranteeing any major performance boost.

So, to answer your question directly as it is phrased, should you ALSO keep your data in a JavaScript data structure, or just in the DOM: You did mention this was a "simple" ajax web app. My recommendation is to try and keep this simple, then! Your example of how you can so easily use jquery to find rows and cells based on search criteria should be enough to convince you to give this a try!

Best of luck!
-Mike

Funka
thank you, funka! addressing your question: I imagine most of the time there being 400-600 rows. I would be "dynamically" filtering that table based on the user selecting checkboxes, eg. Currently the page starts with an empty table and the data is served as JSON from the server.
laramichaels