Re: Paged Results Set in MySQL DB with one result
| From: | Jochem Maas | Date: | Thu, 04 May 2006 10:06:56 +0000 |
| Subject: | Re: Paged Results Set in MySQL DB with one result | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-235461@lists.php.net to get a copy of this message | ||
Richard Lynch wrote:
On Wed, May 3, 2006 6:57 pm, Jochem Maas wrote:dang - I didn't read properly - apologies go out to Edward for that!a. who said anything about sessions?Jay did.
He suggested sucking down the whole article, paginating it all, and cramming the pages into session, presumably so you don't have to suck down the whole article again. Which, by the way, is what I dislike about most of these answers... If the article is REALLY big, a query to get the whole damn thing is slow.agreed - but then caching concepts/implementations of content/data/etc belongs on a whole other level imho.
I made the same assumption.I think the assumption is that the article is actually HTML in the databse...parsing for html comments that could get blasted by an errant edit.the marker is either there or not - and if it'd borked (e.g. '<!-- PAGE MAR') then it would break the page, sure - but so could ANY broken markup so the argument is somewhat moot. besides a routine to strip markers (broken or otherwise) is as simple to write as marker splitting function is.
At which point, almost any pagination you try to do programmatically is just plain borked.absolutely - assuming the programmic pagination is based on 'logic' as opposed to being based on 'commands' (i.e. specific markers) put in place by the author of said article (whihc to me equates to putting seperate 'pages' in seperate records in the DB because the pagination is explicit rather than inferred).