topgfsfurart3dcgdislitrpp2preq

/dis/ - Discussion

Name
Email
Subject
Comment
File
Password (For file deletion.)

 No.6907

So, just a quick question as to why threads on GuroChan don't use pages?
Especially in threads were images are posted, this is seriously annoying, as you have to wait for all the images to load before you can scroll down. (Well, you can try before, but the images will keep on pushing the bottom of the site down until they are all loaded).

So yeah, pages would make life here A LOT easier.
But maybe I'm just not seeing the amazing reason as to why they aren't used?

 No.6918

>>6907
Code complexity is about all, I would expect. Pretty much no *chan type server uses anything like that other than at the section overview level, they're all extremely simple (though Enclaved would probably beg to differ given his rant about having to disentangle the original spaghetti code in order to fix it) PHP/MySQL type affairs.

SELECT FROM TABLE "artwork" WHERE $THREAD = "1429" and all that.

Heck it might even be a simpler filesystem based setup given how the "forum" and "thread" addresses are given... e.g. for this thread, gurochan.cx/dis/res/6907.html ... this is thread #6907, and it's in Discussion, so each new post regenerates the code of page file 6907.html under folder /dis/res on the gurochan server. Loading the page then requires nothing more than reading the html, and any images inlined to it (which are also stored in a big flat pile inside /dis/res, and found by searching their numerical filename). Doesn't even separate threads into their own folders... I mean, I'd expected this to be more index.html in /dis/res/6907, but that's evidently not the case (or at least, what we can see from the client side doesn't reflect that; it might be like that in reality with the server-side software doing some live translation between the apparent and actual filesystems).

Very messy, but still entirely effective, and about as simple as it's possible to make. Writing the files so that they cut each page into sections would require adding an extra level of intelligence to the file authoring code to judge where to split them up and providing the nav links, and either making multiple .html files for each page as it grew (not the most difficult, admittedly, as just adding an underscore and then a pair of hex characters would allow 256 separate pages), or twiddling the CSS to fake that (I've no idea myself how you'd make that work, but presume it's doable; however, your browser would still have to load the entire html file even if not the pictures, and in some text-heavy threads the data load of the text and html code can outweigh that of the thumbnailed images).

Or in other words, if you're that bothered, contact the admin and offer to set it up for him, I'm sure he'd be delighted at not having to fuck with the board code any further in order to provide a change whose benefit is somewhat marginal unless you're stuck on 56k or using an ancient Celeron with very little RAM.

 No.6919

* s/regenerates page code/appends a new post section at the end of the page code (just above the footer)

Like, I doubt it would rewrite the entire page, that would get pretty heavy for the longer ones, and require some kind of separate database or at least creating a temporary single-thread one in the server memory. Much easier to just have each post on a thread marked out with some kind of comment tag (so they can be deleted in a fairly simple manner later on - just erase those particular tags and everything between them, plus any associated image file), and with each new one erase the (standardised) footer, then write in the post data and reappend the footer. The html files themselves become the in-place database, making for a considerable saving in terms of disc space and processing overhead.

 No.6959

SELECT * FROM ThreadPosts WHERE threadId = "whatever" ORDER BY postDateTime LIMIT {postsPerPage*pageNumber}, {postsPerPage};

would work in MySQL.

And pages threads are useful for more than just load times - it helps you save your place. Instead of having to save something you can Ctrl-F to some file, you can just look up the last page of the thread in your browser history - or if you've set up your browser to re-open the last session's tabs, you're immediately back where you left off.

 No.6960

And here's page functionality in JS: pastebin.com/J0rHXEVi

This could easily be made into a browser extension, but for now, do the following to get it working:

1. Append ?page=[n] to the end of a thread URL, where [n] is the page number starting at 1.
2. Reload the page to apply this change.
3. Open the developer tools by pressing F12.
4. Navigate to the "Console" tab.
5. Paste the provided code (see Pastebin link) into the console and press Enter.

 No.7089

And here's a Chrome extension based on the code I posted earlier: chrome.google.com/webstore/detail/gc-pagination/hjchpmmpmlpobmihjoiafhofacfampmf



[Return][Go to top] [Catalog] [Post a Reply]
Delete Post [ ]
topgfsfurart3dcgdislitrpp2preq