Artikel op meerdere pagina´s weergeven

[ilovetechno]

Ik ben bezig met een site waar ik vrij grote artikelen op ga zetten. Nu zit ik met het volgende probleem. Ik wil niet dat de mensen eindeloos moeten scrollen dus ik wil meerdere pagina´s.

Het artikel wordt in een div weergegeven. Het artikel staat als text binnen MySQL. Nu kan ik natuurlijk met het aantal tekens werken.. Dus op pagina 1... alleen teken 1 - 4000 laten zien op pagina 2 4001-8000.. ik kan er dan allemaal truckes in bouwen zodat de woorden worden juist afgebroken enz..

Ik heb dan alleen probleem.. Hoe kan ik zien hoeveel karakters een afbeelding inneemt.. Zodat hij de pagina altijd op de juiste manier afbreekt?

Of denk ik totaal verkeerd en is er een makkelijkere oplossing? Op google/phpfreakz enz.. kon ik niets vinden.

[Wacky]

Waarom bedenk je geen tag waarmee je zelf de pagebreak aangeeft? Bijvoorbeeld:

code:

Blabla einde pagina 1</p>
#pagebreak#
<p>Begin pagina 2

Je kan met PHP eenvoudig #pagebreak# gebruiken om de pagina's in te delen, zo heb je alles zelf in de hand

[samo]

Helemaal eens met Wacky. Maar anders zou je het kunnen laten indelen in <p>'s, en dus pas afbreken na een </p>. Dan weet je tenminste zeker dat de tekst nog een beetje natuurlijk lijkt. En dus wanner er meer dan X aantal woorden zijn geweest, aan het einde van de paragraaf afbreken.
De meest natuurlijke abreking is natuurlijk voor een header element. Is ook een mogelijkheid...

[liledevil]

Ik zou zelf een systeem maken waarbij je verschillende pagina's per artikel kunt opslaan,
dus een table structuur in de trend van

code:

artikel_id|pagina_nr|text

En steeds de mogelijkheid om een pagina per artikel toe te voegen, op deze manier hoef je geen moeilijke algoritmes te gaan bedenken voor het juist afbreken van woorden en het op 1 pagina te houden.

[pietje63]

samo schreef op maandag 06 november 2006 @ 10:12:
Helemaal eens met Wacky. Maar anders zou je het kunnen laten indelen in <p>'s, en dus pas afbreken na een </p>. Dan weet je tenminste zeker dat de tekst nog een beetje natuurlijk lijkt. En dus wanner er meer dan X aantal woorden zijn geweest, aan het einde van de paragraaf afbreken.
De meest natuurlijke abreking is natuurlijk voor een header element. Is ook een mogelijkheid...

Dit vind ik een mooie oplossing! Het vereist wel dat het cms goede html aflevert, maar als je nog aan het bouwen bent zal ik daar sowieso voor zorgen.

De manier die Wacky aandraagt wordt oa door Mamboo gebruikt en is wat flexibeleren, maar vereist wel activiteiten van de gebruiker.

[Verwijderd]

Precies... ik zou met het oog op lay-out altijd zorgen dat jezelf actief beslist over waar een pagina wordt opgebroken... bij automatische toepassingen wordt hij straks opgedeeld in 3 pagina's terwijl op pagina 3 maar 10 woorden staan... niet echt wenselijk denk ik.

De oplossing van Wacky lijkt me een mooie!

[Verwijderd]

Ik vind het helemaal niet logisch om handmatig een pagebreak in te voeren in een artikel. Je bent op dat moment je content aan het vervuilen. Stel dat je die content later ergens anders voor wilt gebruiken. Je bent dan genoodzaakt om je content te filteren op een dergelijke "pagebreak", dus mijn inziens vervuil je de eigenlijke content.

Ik zou ervoor kiezen om een artikel op te delen in meerdere pagina's en deze zo ook in de database op te slaan. Bijvoorbeeld:

+---------+        +---------+
| Artikel |        | Pagina  |
+---------+        +---------+
|      id | <--+   |      id |
|   titel |    +-- |  parent |
+---------+        |    rang |
                   |   tekst |
                   +---------+

Dit is volgens mij puur een stukje normalisatie.

[Anders]

@djingelz - als je in jouw oplossing die content later ergens anders voor wilt gebruiken, moet je de boel weer aan elkaar plakken. Met andere woorden, het moet net zo hard worden geprocessed als dat je een pagebreak eruit zou willen filteren. Alleen komt er in jouw situatie nog het risico bij dat je per ongeluk de volgorde door elkaar husselt, stukken tekst dubbel vermeldt of juist vergeet.

Normalisatie is prima, maar moet geen obsessie worden. Ik ben het daarom in principe (is natuurlijk altijd afhankelijk van de praktijksituatie etc) eens met de oplossing van Wacky.

[liledevil]

Anders schreef op maandag 06 november 2006 @ 13:15:
@djingelz - als je in jouw oplossing die content later ergens anders voor wilt gebruiken, moet je de boel weer aan elkaar plakken. Met andere woorden, het moet net zo hard worden geprocessed als dat je een pagebreak eruit zou willen filteren. Alleen komt er in jouw situatie nog het risico bij dat je per ongeluk de volgorde door elkaar husselt, stukken tekst dubbel vermeldt of juist vergeet.

Normalisatie is prima, maar moet geen obsessie worden. Ik ben het daarom in principe (is natuurlijk altijd afhankelijk van de praktijksituatie etc) eens met de oplossing van Wacky.

Ik had hetzelfde idee als djingelz, wellicht iets minder uitgebreid uitgelegd.
Ik denk dat beide oplossingen gewoon goede oplossingen zijn, maar het heel erg afhankelijk is van de praktijksituatie. Beide hebben hun voor en nadelen, maar dat is programmeren.

[NMe]

Ik zou persoonlijk kiezen voor djingelz' oplossing, domweg omdat ik zelf controle over mijn pagebreaks zou willen hebben en ik daarbij Wacky's oplossing niet echt netjes vind. Dat laatste is overigens persoonlijk, dat hoef je niet met me eens te zijn.

De optie om domweg te kijken naar het aantal karakters, en vanaf dat aantal af te breken na de eerstvolgende </p> (of desnoods na de eerstvolgende dubbele enter) lijkt me ook wel ok, als normaliseren en het vervuilen van de content beiden geen optie zijn.

[liledevil]

-NMe- schreef op maandag 06 november 2006 @ 13:21:
De optie om domweg te kijken naar het aantal karakters, en vanaf dat aantal af te breken na de eerstvolgende </p> (of desnoods na de eerstvolgende dubbele enter) lijkt me ook wel ok, als normaliseren en het vervuilen van de content beiden geen optie zijn.

Wellicht dat het ook een optie is om juist steeds na een </p> tag een nieuwe pagina te laten beginnen.
Voordelen:
Je vervuilt de tekst dan niet
Kan de tekst makkelijk migreren.
Nadelen:
Je moet je volledige tekst iedere keer processen(performance)
Het terugvinden van een stukje tekst in een artikel van 10+ pagina's is iets moeilijker.

[Verwijderd]

Anders schreef op maandag 06 november 2006 @ 13:15:
@djingelz - als je in jouw oplossing die content later ergens anders voor wilt gebruiken, moet je de boel weer aan elkaar plakken.

Keerzijde, de oplossing van Wacky forceert het ophalen van het hele bericht terwijl slechts een deel getoond gaat worden. Mijn voorkeur gaat dus uit naar de oplossing van djingelz.

[Verwijderd]

Anders schreef op maandag 06 november 2006 @ 13:15:
@djingelz - als je in jouw oplossing die content later ergens anders voor wilt gebruiken, moet je de boel weer aan elkaar plakken. Met andere woorden, het moet net zo hard worden geprocessed als dat je een pagebreak eruit zou willen filteren. Alleen komt er in jouw situatie nog het risico bij dat je per ongeluk de volgorde door elkaar husselt, stukken tekst dubbel vermeldt of juist vergeet.

Normalisatie is prima, maar moet geen obsessie worden. Ik ben het daarom in principe (is natuurlijk altijd afhankelijk van de praktijksituatie etc) eens met de oplossing van Wacky.

Ik zeg ook niet dat je met mijn oplossing niets meer hoeft te doen (al hoef je de boel niet aan elkaar te plakken ). Ik zou echter graag een duidelijke scheiding willen tussen content en representatie. Dit bereik je niet door pagebreaks op te nemen in de eigenlijke content, vandaar dat ik voor een andere oplossing zou kiezen.

Verder geef je aan er wellicht meer risico's kleven aan mijn oplossing. Dit durf ik te bestrijden. Een handmatige pagebreak introduceren is mijn inziens gevaarlijker omdat een gebruiker deze zelf in moet voeren. Een typefout is hierbij snel gemaakt en deze fout kan door de gebruiker worden gemaakt. De fouten die jij aan draagt zijn echter fouten die niet door een gebruiker gemaakt kunnen worden maar enkel door degene die de code schrijft. En er is dus niets aan de hand als je deze code goed schrijft.

Dit wil overigens niet zeggen dat ik de andere twee oplossing onacceptabel vind. Er zijn scenario's te bedenken waarbij ze misschien wel te gebruiken zijn al vind ik het handmatig invoeren van pagebreaks de minst logische. Het dynamisch genereren kan bijvoorbeeld nog interessant zijn als je gebruik maakt van bepaalde instellingen van een gebruiker.

Maar al met al blijft het inderdaad een persoonlijke keuze waarbij ik voor mijn oplossing zou kiezen

[djluc]

Je kan beter kijken naar de opbouw van het document. Stel het document is opgebouwd in nette
HTML met headers:
<h2>
<h3>beetje
<h3>veel
<h3>beetje
<h2>
<h3>beetje
</h3>beetje

Dan zou je kunnen bepalen in je code om de h3's onder de eerste h2 allen als aparte pagina's te laten zien terwijl je bij de 2e alles op 1 pagina plaatst.

[wackmaniac]

Verwijderd schreef op maandag 06 november 2006 @ 10:40:Je bent dan genoodzaakt om je content te filteren op een dergelijke "pagebreak", dus mijn inziens vervuil je de eigenlijke content.

Stel dat je ubb tags gebruikt, dan vervuil je je content net zo hard. Dit gaat in principe alleen op voor als je de html-code opslaat, lijkt mij.
De oplossing van djluc is in principe een nette variant van dit geheel.

[ Voor 12% gewijzigd door wackmaniac op 06-11-2006 15:58 ]