On May 4, 2006, at 4:16 AM, Richard Lynch wrote:
On Wed, May 3, 2006 6:57 pm, Jochem Maas wrote:
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.
That was my thought. Plus if the user closes the browser you loose
the session(usually, for anonymous sessions, not logged in users),
then you have to do the processing/session storing all over again if
they wanted to look at it again right away. Multiply by a couple
thousand and your server is doing a lot of work it really doesn't
have to if the 'pages' are pre-set and you're only grabbing a small
chunk at a time. Plus you can get relevant urls to a 'page' that can
be bookmarked, to a degree.
Aside from not having to do a lot of text processing, the queries
would be simpler too. And the author would still have control over
the length of the 'pages', which is probably much preferable to some
kind of automatic system that has no concept of context.
I'm not saying all of the 'pages' would be exactly the same length,
but they would make sense as pages when you read them, if the author
knew what they were doing.
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.
I think the assumption is that the article is actually HTML in the
databse...
I wasn't making that assumption.
define('HTML_stored_in_the_DB_for_dynamic_content', 'bad'); // IMHO :)
What if you write a cool pdf generator (or rss feed or
whateverNewThingComesAlong) in a couple years to deliver those
articles? Wouldn't it be easier to adapt a tag replacer that you
already have ( because you're not storing the html, and folks want to
be able to make a word bold in the web page 'cause they can do it in
MSWord :P) to other formats than try to write an html parser from
scratch? (Yeah, I know that you still have the danger of users
borking the replacement tags, no idea is perfect)
Plus having easy access to 'sections' of articles means that those
sections aren't necessarily tied to a particular article. Mix and
match(repurpose) anyone?
As a personal note, I prefer to read things that have been broken up
into logical chunks for me, as opposed to being fed some 2000 word
essay all at once. I *hate* scrolling. But then I didn't learn to
read on a computer screen either.
Ed
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
