Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #23600 > unrolled thread

Searching a multi page list

Back to article view | Back to comp.lang.javascript

Contents

  Searching a multi page list Andrew Poulos <ap_prog@hotmail.com> - 2014-03-14 13:57 +1100
    Re: Searching a multi page list Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-03-14 10:59 +0100
    Re: Searching a multi page list Denis McMahon <denismfmcmahon@gmail.com> - 2014-03-15 00:13 +0000
      Re: Searching a multi page list Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-03-15 01:29 +0100

#23600 — Searching a multi page list

I query a database and display the returned records in a list. If the 
list gets too long I split it and display only the first "page" (with 
next/back buttons to get to the other "pages").

I needed a search capability so I wrote one that can search a list and 
create a new list based on the matches. Alas it only works on a single 
list. If a big list is actually a series of multiple lists what's a 
decent way of adding a search capability?

Should I have a "hidden" list with every item and then create the 
displayed list(s) from it?

Andrew Poulos

[toc] | [next] | [standalone]

#23601

Andrew Poulos wrote:

> I query a database and display the returned records in a list. If the
> list gets too long I split it and display only the first "page" (with
> next/back buttons to get to the other "pages").
> 
> I needed a search capability so I wrote one that can search a list and
> create a new list based on the matches. Alas it only works on a single
> list. If a big list is actually a series of multiple lists what's a
> decent way of adding a search capability?

Filter the data server-side, use XHR on the client to request the results, 
and the DOM to generate the markup.  Since you would probably prefer XHR 
anyway in order to get the latest data efficiently and user-friendly when 
turning the page, no major modifications to the business logic would be 
necessary.

The worse alternative is to send the client the whole list, but generate 
only a part of it (per page) either server-side or client-side.

> Should I have a "hidden" list with every item and then create the
> displayed list(s) from it?

Then it would not work without client-side scripting, and initial loading 
would take longer.  Also, the search would be on the last snapshot of the 
data, not necessarily the current data.

Note that either way you can cache the data server-side in a session, 
potentially reducing database load.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#23604

On Fri, 14 Mar 2014 13:57:03 +1100, Andrew Poulos wrote:

> I query a database and display the returned records in a list. If the
> list gets too long I split it and display only the first "page" (with
> next/back buttons to get to the other "pages").
> 
> I needed a search capability so I wrote one that can search a list and
> create a new list based on the matches. Alas it only works on a single
> list. If a big list is actually a series of multiple lists what's a
> decent way of adding a search capability?
> 
> Should I have a "hidden" list with every item and then create the
> displayed list(s) from it?

Depends how much effort you want to do server side, and how much you want 
to do client side. I'd suggest that you don't want to do the same work in 
both places.

If you pass the main list to your page as a json object, presumably you 
could generate the sub pages in the client, and also provide a filtering 
system in the client to select just those elements matching some criteria.

It might even be possible to size each sub-list to fit in a single screen 
of the users viewport, which might make the user experience better than 
having to scroll and and next / prev.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#23605

Denis McMahon wrote:

> On Fri, 14 Mar 2014 13:57:03 +1100, Andrew Poulos wrote: 
>> I query a database and display the returned records in a list. If the
>> list gets too long I split it and display only the first "page" (with
>> next/back buttons to get to the other "pages").
>> 
>> I needed a search capability so I wrote one that can search a list and
>> create a new list based on the matches. Alas it only works on a single
>> list. If a big list is actually a series of multiple lists what's a
>> decent way of adding a search capability?
>> 
>> Should I have a "hidden" list with every item and then create the
>> displayed list(s) from it?
> 
> Depends how much effort you want to do server side, and how much you want
> to do client side. I'd suggest that you don't want to do the same work in
> both places.

Which is why the server just needs a(n MVC controller action) method to 
generate the *partial* list, optionally as JSON (or whatever data format) 
instead of HTML.  That really is an old hat in Web development now.

> If you pass the main list to your page as a json object,

There are no “json object[s]” (except *the* “JSON” object); that is a 
fundamental (but unfortunately common) misconception.  JSON is the 
JavaScript Object *Notation*, a subset of ECMAScript literal syntax.  You 
can make an *ECMAScript* object (an Object or Array instance) out of that 
notation, efficiently now (ES5+) using JSON.parse().

> presumably you could generate the sub pages in the client, and also
> provide a filtering system in the client to select just those elements
> matching some criteria.
> 
> It might even be possible to size each sub-list to fit in a single screen
> of the users viewport, which might make the user experience better than
> having to scroll and and next / prev.

You are missing the point.  Serving/parsing/rendering whole lists 
(presumably, tables) to the client in the same document takes a lot of 
resources and is simply not feasible with a lot of data (the 5±2 rule of 
usability notwithstanding).  For that it does not matter if the lists are 
visually split up or if they are temporarily hidden as long as they are in 
the same document.  So a solution to this problem must include that the 
document does _not_ contain the data/markup for the whole list.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web