× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> Why?  Why not provide a page at a time?  This seems wasteful...
Users request. They found it to be much slower for them to click & re-load
next page or previous page. In this app users doing property searches
based on various search criteria. I wouldn't do this for just any app, but
I think user requirements should definitely be considered. In my case, there
may be many records (normally too many for one page) related to a single
search request, and using the slide bar, the user could quickly visually
review
all before making a selection.
If you are concerned about the processor requirement, think of a single user
clicking 100 times for next page, versus one large load?
I don't think there is a general rule to fit all apps.
jim franz

----- Original Message -----
From: "Rich Duzenbury" <rduz@westernmidrange.com>
To: <web400@midrange.com>
Sent: Tuesday, December 03, 2002 12:09 AM
Subject: Re: [WEB400] How to present large datasets on the Web?


> At 09:45 PM 12/2/02, you wrote:
> > > Um, nobody looks at 5000 records at a shot, do they?
>
>
> >yes they do...
> >In some pages is is 20 records at a time (like any search engine returns
the
> >1st page as 1 of 2,000,000)
>
> Yes, this I expect to see.  And a 20 (or 50, or 100) records at a time,
> this is efficient and effective.  5000 records on one page seems wrong, in
> the general case.
>
> >In some I return the whole set in html, usually not more than a minute or
2
> >to load.
>
> Why?  Why not provide a page at a time?  This seems wasteful.  I have my
> google preferences set to return 100 at a shot, and I find that I will
look
> through 100, or even 200 links, but 5000?  No way.  And why wait two
> minutes to see a screen.  On the iSeries, my customers expect sub-second
> response.  Not multi minute response.
>
> >Also provide a link to save the whole set in a .csv file from the ifs.
They
> >can use it in Excel.
>
> Fine, I do this, too.  But I can still provide a link to all the data, yet
> display one page at a time to the browser.
>
> >jim
> >----- Original Message -----
> >From: "Rich Duzenbury" <rduz@westernmidrange.com>
> >To: <web400@midrange.com>
> >Sent: Monday, December 02, 2002 7:14 PM
> >Subject: Re: [WEB400] How to present large datasets on the Web?
> >
> >
> > > So.  Has anyone tried to routinely display a list that contains five
or
> >ten
> > > >thousand entries on the web?  What architectural approach did you
take?
> > > >   --buck
> > >
> > > Um, nobody looks at 5000 records at a shot, do they?
> > >
> > > You need to invent a subfile mechanism - You know - 'get the next page
of
> > > records', 'get the previous page of records', and so on.  Have your
java
> > > person call your program and give it a selected page number as a
> > > parameter.  Your RPG program locates that page of records and returns
it.
> > >
> > > It would even be fun to add filtering and sorting capabilities - You
know,
> > > longest telephone calls, highest cost calls, and so forth.  Resequence
the
> > > display by number dialed.
> > >
> > >
> > >
> > > Regards,
> > > Rich
> > >
>
> Regards,
> Rich
>
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> or email: WEB400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>
>




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.