I have a web home page that has a search box that passes values to a custom inet_ procedure.

This procedure uses Rlist to select the items from the OI database, saves to a list in syslist then calls another inet_searchresults proc to build the html search results page.

What I would like to do is, on the search results page have a "Next" and "Previous" link. I only want to display 10 items per page and then have the iuser be able to click next for the next ten.

I know I can do this with the save list and when the "next" or "previous" is clicked call the same inet_searchresults proc

passing it a counter as to where in the save list to start processing.

My question is, is this an efficient way of handling this?

It seems to me that the system will be doing alot of save-lists and

get-lists based on a unique list id for each iuser.

I was wondering how others may have handled this or any suggestions.

Thanks

Bruce,

I had a similar problem, and here's how I solved it.

I too wanted to show a result list in chunks. But instead of Previous and Next buttons I offer "random access". E.g, let's say the search found 333 hits. At the bottom of my result page I then display a list of ranges: 1-10 11-20 21-30 … 321-330 331-333. (I have them as links and not as buttons, but that's not an important point.) So the user can pick any chunk. E.g, if he clicks 21-30 he gets to see the third chunk of the result list, with hits 21, 22, … 30.

When you do a search and save the result to SYSLISTS, you get one or more SYSLISTS rows. One row if there are not too many hits, several if many hits. So your result list is like an array spanning one or more SYSLISTS rows. The rows are named , *2, *3, …, *n.

So your result list might indeed be divided into chunks, but very large ones, and of slightly uneven size. Before I tackled the problem I thought it would be nice if one could get Save_Select to store the result list with a certain chunk size (e.g, 10), but that's not possible.

One could of course have some programming that immediately reorganized the list into rows with smaller chunks, perhaps in a different table than SYSLIST. But that could take too much time on anything but small lists.

But instead of reorganizing physically, what I chose to do was to to establish an array with information about each chunk. For each chunk there is information about where it starts and ends - which of the n SYSLISTS rows and byte position within the row. I keep this chunk information in a special SYSLIST row _CHUNKS, but perhaps a common block is possible too.

To access chunks I just read SYSLISTS rows, and extract the proper key sequences. So I don't reactivate the list with Activate_Save_Select or anything.

To keep processing overhead low I don't generate all the chunk information immediately. I wait and see if the user really requests a certain chunk. Well, what I actually do is immediately generate the chunk info for the first SYSLISTS row, but wait with later rows until the user requests a chunk from another row.

There's some icky stuff where chunks span two rows, but it's not too difficult.

Hope I got you right and didn't miss your question completely.

- Oystein -

Bruce,

One possible problem with my approach: With short keys and short chunks the chunk info might become almost as large as the original result list. My chunks are not as small as 10, and my keys are typically 12-15 characters long.

But if by any chance your keys are of fixed length the chunk info boils down to almost nothing.

And if you stick with your Previous/Next approach, you might perhaps make do with keeping track of where the current chunk is. When the user requests the next or previous chunk, just read the relevant SYSLISTS row and calculate from there.

- Oystein -

Oystein,

Thanks I was thinking along the same lines.

One thing that bothered me was that if 100+ people

were doing searches than updating syslists is getting alot of

work.

What I thought about was to put the keys into the link.

My keys are 5 digits long and I could just store them in the

web page. (e.g. <a ahref=../oicgi.exe/inet_nextlist?keys=xxxx*xxxx*xxxx)

The problem with that is that I would still need the savelist

and keep track of what keys were where. But, maybe I could incorporate your idea of Page - 1 2 3 4 5 etc.

I think I would have between 300-500 items at most to list and could

just limit it. In this case a search result that large means the

iuser needs to be more specific.

Thanks, I'll keep plugg'n at it.

Bruce

Thanks I was thinking along the same lines. One thing that bothered me was that if 100+ people were doing searches than updating syslists is getting alot of work.

I dunno really. I haven't stress tested my app yet.

But I have done all I can to make sure the queries are executed quickly.

What I thought about was to put the keys into the link. My keys are 5 digits long and I could just store them in the web page. (e.g. . row, right? (And it keeps the 10 last W rows. And keeps track of them in a Q row.) Is this what you're talking about? That it seems so unnecessary to have Save_Select make an additional copy? But that was the only solution I found. The system must be able to distinguish between different users' lists, and keep them from each other. I Save_Select them under a name that includes the user's ip number. It would be nice if one could tell Rlist to store with a user defined name instead of a W name. That's not possible. (But perhaps there's some other simple solution that I overlooked.) and keep track of what keys were where. But, maybe I could incorporate your idea of Page - 1 2 3 4 5 etc. I think I would have between 300-500 items at most to list and could just limit it. You might have to limit it. You might find that large chunk/page lists make your dynamic html document break the 64K limit. Major nuisance! In this case a search result that large means the iuser needs to be more specific. I can think of cases where a large list makes sense. Sometimes it can be difficult for the user to find specific enough search criteria. It can be the user's fault, the data's fault, or the interface and app programming's fault. Anyway he has to do with criteria that are "wider" than ideal. But especially when the result list is sorted he can still find nuggets. Sometimes with a sorted list the user knows approximately where to start browsing. - Oystein - </QUOTE> —- === At 29 JUN 2000 03:44PM B. Cameron wrote: === <QUOTE>Oy, Maybe I'm not making sense. Call Rlist(Cmd, 4, 'bruce1', , )will save an item to SYSLISTS named bruce1. Row one looks like -]] 11869.4475462963 BMC 93 I'm not sure what each part is but looks like ? date.time user ? ? So it sounds like this is redunant but how would I know which list to get when the rlist call without 'bruce1' is made in inet_readrec which onced processed calls inet_searchresults to build the page. Bruce (Oops nnnnn*nnnnn*nnnnn ;]) </QUOTE> —- === At 29 JUN 2000 05:14PM The Sprezzatura Group wrote: === <QUOTE>Bruce, We've taken S/LIST 2.0 and converted it over to web processing thus creating INET_SLIST. You might find this a more sensible solution than trying to get INET_RLIST to run correctly. Give a call or email to the office and we'll explain the finer details. The Sprezzatura Group World leaders in all things RevSoft[/i]

Bruce,

Maybe I'm not making sense. Call Rlist(Cmd, 4, 'bruce1', , )will save an item to SYSLISTS named bruce1.

Sorry! You're right of course!

But you do get the W row too, with identical content to the BRUCE1 row. Which means the system does some extra work. Which we'd like to avoid in a resource-critical web app.

Row one looks like -]] 11869.4475462963 BMC 93 I'm not sure what each part is but looks like ? date.time user ? ?

This is field one of row one, yes. It's the result list's header. It's something like

@SVM date.time @SVM user @SVM number-of-hits @SVM comment

(The commment is user defined. It's there if you need to store a comment along with your result list. But I don't think you can set it with Rlist. I think you must use Save_Select.)

So it sounds like this is redunant but how would I know which list to get when the rlist call without 'bruce1' is made in inet_readrec which onced processed calls inet_searchresults to build the page.

I assume the inet function which does the Rlist could find out which W list it was. It must be the one with the highest date.time value in its name. The Q row contains all the W row names, so it could find out by checking the Q row.

(Or is it thinkable that the processing yields to another web user, so that other user sneaks in a new W row before you managed to check???? So you get his list instead? I don't think so.)

And then you could include the W row name in your html form, along with your chunk/page number. See?

But it will not work. The system stores only the last 10 W rows. By the time the user responds, 10 other users can have made 10 new W rows, losing your row.

- Oystein -

View this thread on the forum...