web counter, next-page method?

Here is what you should do, how you do it is just a matter of your own preferences. Not so much code, but a design. When your data is returned, you chop the first n entries of, where n is the number of rows you want to display. You will also have an offset o, initially zero and growing with n on each page. Now you'll also need a way to make the query "persistent" over multiple pages. You could do this using some session mechanism, where you link the session-id to a query-id and the query is stored. Or you could bluntly encode the query using simple symmetric encoding with blowfish, or easier, the core-based functions 'encloak and 'decloak. So we have right now references to: the query, the offset (basically the starting row) and how many rows to come. Now: the CGI function that executes the query takes two extra parameters, the offset and the number of rows to return. You can use SQL or REBOL to use those two values. I'd start with REBOL, doing an 'at and 'copy/part on the returned series, and if that works start optimizing the SQL. Your "Next" button / image / link simply is a GET/POST to the query supplying the offset and number of rows. The same for a previous button, but then backwards. --Maarten

Maarten and Hallvard have given good replies, to which I'd add that using the query-string to keep track of both the search-query and page-number is a good idea, as then people can bookmark their searches. ie, something like this... www.someplace.com/db ; search for "da do" returns... www.someplace.com/db?search=da+do ; next-page clicked returns... www.someplace.com/db?search=da+do&skip=30 This also has the advantage of allowing people to edit the query by hand, thus jumping to near the end (say) of a large result by changing skip=30 to skip=300. Useful if the results have been sorted. There's a slight problem with that in that the database may change before the next-page button is clicked on, so you might be skipping over data you really should be displaying. You could get around that by keeping a tempory file of the full search results and have an id pointing to it, but then it might show items that are no longer in the database so it's really six of one and half a dozen of the other. The closest thing I've done to this is... http://cybercraft.nebularis.com/NZnews/NZnews-home.r but it doesn't use SQL and the search just stops at about 500 results - no paging ;-) But where you are is all tracked by the query string, so if you're looking at a weeks' results for a date and change the date, you still get a week's results. -- Carl Read

If your DB supports rowid, and your table is query-only, then it is probably more efficient to return a block of rowid's and then cycle through them n rowids at a time with something like: select * from table where rowid in (...) Regards, Ashley

OK, guys, all fine answers. As for DB aproach pov, I think I can manage it, as I have some db background. Maybe I expressed myself a bit incorrectly. My "problem" is that of how to visually represent that. As I already said - I don't do gfx + html. It is done by our gfx folk. I can fill-in the table with appropriate info, but I was asked what should designer do to represent "next-page" visually. e.g. - once on first page, you can represent your results as: (1) 2 3 4 ->> - you click "2", you get - <<-- 1 (2) 3 4 --> Those page-continuation sections, can have various visual representations - as e.g. with counter - you can use html only with clear text, or you can compose it with bitmaps, etc. But there is no if, then, else awailable with html. So my question is, what is the right aproach to build html template for me to just fill in the data. Maybe the only solution is that designer marks html section where such next-page section will be placed, and it will be separated in another few templates I will have to plug-in? As you can see with above example, it is rather dynamic - when you start, there is no back button, as you move to (2), there is the back button, once you reach (4), there will be no forward button, etc. -pekr-

Ah.

No, he could include it in the main template, with a tag marking where the start and end of [back-page] [pages] and [next-page] are to go (or not to go), along with a word in the HTML indicating where your URL is to be inserted. (He could then change the template later without you needing to change your code.) Then your CGI would parse the template and add (or not add) the HTML (and insert an URL) to the page being output based on how many pages of results there are and on what page you're on... the back-page: if page > 1 [insert back-page-button] for pages: if pages > 1 [insert pages-buttons] for next-page: if page < pages [insert next-page-button] As I assume your CGI must be adding the results to the output too, the format you use for the page tages in the template should match those for the results, so your parsing is looking for the same tags for both in the template. The results are dynamic too of course, as they'll not always having 30 items in them, so not too dissimilar to generating the pages buttons.

db, I have template system, where I simply put data into table or whatever xhtml structure. Now what I am not sure about how to do is - e.g. my table will have 30 rows, db query returns 150 rows, so I need to introduce some next-page continuation mechanism. Any suggestions? How about showing all the rows on one page? :) When using a LAN network or even a highspeed internet access between the webserver and the client browser, usually the longest delay is the browser laying out the page, but once that's done, the user can easily use the browser's scroll bars to view any part of the results. As an example, I've been creating HTML pages that are several megabytes in size, which can generate a printed report that is several hundred pages long. -- Andrew J Martin No paper-less office 'round here! ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

That's the approach we use at REBOL.org -- seems to work okay. Perhaps using RSP -- REBOL Server pages -- would help automate this sort of thing: http://www.shlik.org/rsp/ For paged displays at REBOL.org, we add two parameters to the URL, start-atand limit=, for example: http://www.rebol.org/cgi-bin/cgiwrap/rebol/cpt-view-users.r?start-at=31&limit30 That gives power users the opportunity to edit the URL by hand -- example, to see all users on one page: http://www.rebol.org/cgi-bin/cgiwrap/rebol/cpt-view-users.r?start-at=1&limit=9 9999 Hallvard:

Session ids are likely to upset search engines (they'll see a different URL each time they retrieve the same page, and may index none of them). But cookies upset users who don't or can't use them. With session ids, and Google, the two basic rules are: 1. don't use ID=xxxxxxxx as a CGI parameter name. It explicitly looks for IDand backs off, assuming it is a session id. 2. don't use anything that looks like a session id, so: S=1234 doesn't look like a session id (it's not ID= and the parameter is not a long string of apparently random characters) Best to have strings that are short. Especially, don't use integers above 9999. We do something like that at REBOL.org, so: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rml239098 and: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlCTNQ both get you the same message, but the first probably looks like a session- id while the second probably doesn't. None of this matters if you don't want ot need the pages to be indexed by search engines. Sunanda.