web counter, next-page method?
[1/9] from: petr:krenzelok:trz:cz at: 7-Apr-2004 9:45
Hi, I will soon prepare some part of portal. Let's suppose I get data from 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? That is not about search & replace only. xtml template is designed by our gfx designer, cgi/data part is mine responsibility. We just set yesterday and our designer asked, what should he put into xhtml template? And now I am not sure how to do it. Maybe it could use similar aproach as when you construct gfx based counter? Dunno. Any suggestions, examples? Thanks, -pekr-
[2/9] from: maarten:vrijheid at: 7-Apr-2004 10:38
> I will soon prepare some part of portal. Let's suppose I get data from > db, I have template system, where I simply put data into table or
<<quoted lines omitted: 6>>> I am not sure how to do it. Maybe it could use similar aproach as when > you construct gfx based counter? Dunno. Any suggestions, examples?
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
[3/9] from: hallvard:ystad:oops-as:no at: 7-Apr-2004 16:47
Hi, Petr, I see Marten had good answers to this. Look at them first! Here's what I do with the RIX (uses MySQL and DocKimbel's mysql-protocol.r): I use LIMIT in the DB-command, and fetch only, say, the first ten records: LIMIT 10 Bottom of page, I have a "next 10 occurances" link. Click it, and I do LIMIT 10, 10 Which fetches only 10 records, starting at 10. Persistent connections / sessions would be better, but I didn't bother using cookies or figuring out a good way to make session IDs and putting them in the url. Guess this is easier with FastCGI. Was this to any help? HY Dixit Petr Krenzelok (09.45 07.04.2004):
[4/9] from: carl:cybercraft at: 8-Apr-2004 6:52
On 07-Apr-04, Petr Krenzelok wrote:
> Hi, > I will soon prepare some part of portal. Let's suppose I get data
<<quoted lines omitted: 8>>> it. Maybe it could use similar aproach as when you construct gfx > based counter? Dunno. Any suggestions, examples?
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
[5/9] from: atruter:labyrinth:au at: 8-Apr-2004 9:06
> I use LIMIT in the DB-command ...
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
[6/9] from: petr:krenzelok:trz:cz at: 8-Apr-2004 4:59
Hallvard Ystad wrote:
>Hi, Petr, >I see Marten had good answers to this. Look at them first!
<<quoted lines omitted: 6>>>Was this to any help? >HY
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-
[7/9] from: carl:cybercraft at: 8-Apr-2004 16:36
>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
<<quoted lines omitted: 5>>>- 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
<<quoted lines omitted: 7>>>move to (2), there is the back button, once you reach (4), there will be >no forward button, etc.
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.
[8/9] from: AJMartin:orcon at: 8-Apr-2004 17:49
> I will soon prepare some part of portal. Let's suppose I get data from
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/
[9/9] from: SunandaDH::aol::com at: 8-Apr-2004 3:30
> 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?
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:
> Persistent connections / sessions would be better, but I didn't bother > using cookies or figuring out a good way to make session IDs and > putting them in the url. Guess this is easier with FastCGI.
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.
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted