Prev: SlickSpeed: jquery vs mylib
Next: FAQ Topic - How do I format a Date object with javascript? (2010-01-27)
From: Matt Kruse on 1 Feb 2010 09:55
On Feb 1, 5:36 am, "Evertjan." <exjxw.hannivo...(a)interxnl.net> wrote:
> Matt Kruse wrote on 01 feb 2010 in comp.lang.javascript:
> > That's a very simplistic view of the web. Tables with thousands of
> > rows are not uncommon in some situations.
> Bad implementations are not uncommon on the web, Matt,
> so commonness does not imply solution quality or logic.

In webappps, for example, long results tables can be very handy to
sort, filter, and manipulate on the client-side. It is much faster
than going back to the server each time, and can be done off-line.
Getting a "dump" of data into a static html document to be handled
later is handy.

Long tables are also good for scanning and getting a feel for how the
results relate to each other. For example, if the rows are colored by
some scheme or if there is a horizontal bar chart in each row, then
scrolling up and down on the table can give the user a quick visual
idea of how the data relates and where logical chunks or groupings of
data exist.

> > that inefficient solutions perform
> > just as well as more optimized solutions.
> What can be inefficient or optimized about solutions
> that "perform just as well"?

There are cases, even without long tables, where the efficiency of a
sort algorithm matter. For example, try creating a more complex table
with multiple tbody tags, a tfoot, colspans and rowspans, more than 25
columns containing complex markup, etc. An inefficient solution may
become unusable with only a couple hundred rows.

During my testing and optimizing of my table sort code, I found that
optimizing for IE6 makes a big difference. Even on shorter tables, you
can cut a second or more off the user's sort time. That is huge in
terms of the user's perception of how quickly the application is
responding.

> Short, easily readable and easily debuggable code
> is the only efficiency gain to be won when the performance is just as well.

Don't forget flexibility. Your shorter code works in the most
simplistic of cases, but if a developer is faced with a situation
where it breaks, they may not know how to fix it. There are pros and
cons to each way of doing it. Which is why "simplest and best" in the
subject is asking for too much!

Simple, Efficient, Robust. Pick two!

Matt Kruse
From: Evertjan. on 1 Feb 2010 11:24
Matt Kruse wrote on 01 feb 2010 in comp.lang.javascript:

> Which is why "simplest and best" in the
> subject is asking for too much!

Here we agree.

There is no "best way" without acounting for personal taste.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
From: Dr J R Stockton on 28 Feb 2010 17:38
In comp.lang.javascript message <doraymeRidThis-D68949.08194927012010(a)ne
ws.albasani.net>, Wed, 27 Jan 2010 08:19:49, dorayme <doraymeRidThis(a)opt
usnet.com.au> posted:
>What is best js to provide for client side column sorting with
>html tables? Be nice to have the cursor change to a hand on
>hovering the table headings. Thank you.

Don't sort the table.

Instead, maintain the data in JavaScript and, on demand, sort it (or a
copy of it) there. Then write the table, with DOM methods.

I have code to sort UK postcodes on my site. Sorting mixed
multinational postal codes should be fun.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: SlickSpeed: jquery vs mylib
Next: FAQ Topic - How do I format a Date object with javascript? (2010-01-27)