So I have a table that displays some columns of numbers and allows users to enter numeric data in some other columns and does all sorts of calculations on these numbers in front-end code. Some calculations go by rows and others by columns. I have it all working very nicely, but I'm now having a crisis of confidence over a couple aspects of it.
(1) In order to treat rows as such, I've used the above code to grab a columns of cells (using classes importantColumn1 and importantColumn2, added to the cells when the table is generated in server-side code) to give table cells ids such as importantColumn1_1, importantColumn1_2, and importantColumn2_1 and importantColumn2_2, and so forth. Later to do some row calculations, I use these ids to gather up all the necessary "row 1", then "row 2" values, and so forth.
(If you're asking yourself the obvious question why I can't I generate anything row-like server-side, it's because this is all coming from a big application framework thingy and given the way it auto-generates table rows when retrieving from a data source I can't.)
For this to work correctly, my code is relying on each() processing the elements in the order they're found on the table (which assumes they're kept in that order in the wrapped set). My question is whether that is a safe assumption.
If it isn't, I've thought of another approach to assigning those pesky ids, starting from the rows.
If folks say, "what's with all these ids anyhow?
you should doing things like this..." I'm all ears.
(2) Is it totally cheesy to assign cells a class like "importantColumn1" just to use the class in other code to treat those cells as a column? I also worked out an approach that used column indexing. (Using index() and nth-child() and such and learning about 0-based vs. 1-based indexing. Whee!)