[PHP/JS]Het converten van BBcoden:client side vs server side

[Anoniem: 162148]

Ik heb 2 vragen m.b.t. het gebruik van UBB code in een forum, gastenboek (of andere aplicatie waarbij users stuk text submitten).

Je kan ervoor kiezen om:
Optie 1: de ingevoerde text, die dus UBB-tags bevat, op te slaan in de database, en bij het showen van een topic/gastenboek-entry, de code converten. (UBB -> HTML)
Voordeel:
- Je hoeft niet te decoderen (HTML->UBB) (als iemand zijn/haar text wilt editten).
- Geen HTML in je database.
Nadeel:
- Het showen van een topic/gastenboek-entry duurt iets langer.
Optie 2: Eerst de UBB code converten en dan pas opslaan.
Voodeel:
- Het showen van een topic/gastenboek-entry duurt niet iets langer.
Nadeel:
- Je moet ook een decodeer-functie schrijven
- HTML tags in je database.
Vraag 1: Voor welke optie zou je kiezen.

Nu zit ik te denken waar zou je dat niet aan client-side kunnen doen? Ik heb zit googlen maar blijkbaar is niet iedereen enthousiat over het converten van UBB code aan client side.
Lijkt me toch heel handig:
-Tis veilig.
-Snel
-Je hoeft geen decodeer-funtien te schrijven?
Vraag 2 is dus: Is UBB code converten dmv JavaScript een goed idee?

[JeRa]

Ik stel een extra optie voor: sla zowel de broncode als het geparsede resultaat op in de database.

Nadeel: meer ruimte benodigt in de database.
Voordeel: niet meer de in de OP genoemde problemen

[Anoniem: 26306]

1: Opslaan in de database als UBB code én als HTML code.
Zo heb je altijd het origineel als iemand een bericht wil veranderen, en hoef je de conversie naar HTML alleen bij het opslaan van een bericht te doen.

2: Nee. Bied goede HTML aan zodat alle user agents die HTML begrijpen er iets mee kunnen. Dat zijn dus ook zoekmachines en dergelijke.

[RobIII]

1) Je kunt ook een combinatie kiezen (dus beide opslaan). Zo kan men, bij het editen gewoon de originele (inc. UBB codes) waardes uit de DB halen, en bij het opslaan sla je tevens de geconverteerde content op. Kost je wel (ong.) dubbel zoveel ruimte, maar is het beste van 2 werelden
Waarom client-side gaan liggen rommelen met javascripts en whatnots; dat is veel te foutgevoelig. Ten eerste heb je dan geen controle er meer over (alles wat van een client komt is onbetrouwbaar en dus al helemaal niet veilig), en dat kleine beetje performance dat je nu aan de client overgeeft is de moeite niet waard.

2) Nee.

edit:

Tjees, type ik ook eens wat

[ Voor 3% gewijzigd door RobIII op 24-08-2006 19:40 ]

[Sybr_E-N]

Er zijn veel meer opties voor vraag 1.
Zo kun je ook bij het toevoegen van een reactie de boel converteren. Hoef je het maar 1x te doen en er is geen vertraging bij het laten zien van alle reacties. Dan is er nog 1 sub mogelijkheid, om zowel de originele als de geparste gegevens op te slaan. Dat in verband met edit mogelijkheiden, en ingewikkelde terug convert script tegen te gaan.
"Geen HTML in je database" Waarom zou je dan niet willen? Het is gewoon ingevoerde data, waarom zou je dat niet gewoon opslaan.

Over vraag 2:
"Tis veilig" Hoezo? kom eens met wat argumenten over deze "veiligheid"
"Snel". Het opbouwen van de pagina zou in theorie zijn langer zijn.
"Je hoeft geen decodeer-funtien te schrijven?" Hoe bedoel je?
Mijn antwoord op vraag 2? Nee. Het kan, maar is niet wenselijk. Waarom zou je informatie zoals UBB codes weer terug willen sturen naar de browser? Ik zie daar het nut niet van in.

[aex351]

Anoniem: 26306 schreef op donderdag 24 augustus 2006 @ 19:38:
1: Opslaan in de database als UBB code én als HTML code.
Zo heb je altijd het origineel als iemand een bericht wil veranderen, en hoef je de conversie naar HTML alleen bij het opslaan van een bericht te doen.

2: Nee. Bied goede HTML aan zodat alle user agents die HTML begrijpen er iets mee kunnen. Dat zijn dus ook zoekmachines en dergelijke.

dat zou dus dubbel data beteken, wanneer een gedeelte corrupt is heb je een probleem met inconsisten gegevens. Ik zou het opslaan als BB code en mij uitvoer converteren.

[Borizz]

Het is verstandig om altijd de UBB code in de database op te slaan! Zo kan je altijd aan de presentatie kant (HTML) aanpassingen doorvoeren aan de gegenereerde code van deze UBB tags!

Bijvoorbeeld:
Vroeger werd een UBB b tag vaak omgezet in html b tags

HTML:

<b>bold</b>

Maar nu wordt het vaak op de volgende manier gedaan:

HTML:

<span style="font-weight: bold">bold</span>

of zo:

HTML:

<strong>bold</strong>

Als je gelijk de conversie maakt van UBB naar HTML (op de server of client maakt dan niets uit) dan heb je niet de flexibiliteit om te switchen. Daar komt bij dat je bij het wijzigen van een bericht de HTML code zou moeten editten of de HTML code terug zou moeten parsen naar UBB..

[RobIII]

aex351 schreef op donderdag 24 augustus 2006 @ 19:42:
[...]

dat zou dus dubbel data beteken, wanneer een gedeelte corrupt is heb je een probleem met inconsisten gegevens. Ik zou het opslaan als BB code en mij uitvoer converteren.

Dubbele data ja, maar wel het beste van 2 werelden. Ten eerste is het onzin om bij iedere view het bericht opnieuw van UBB->HTML te converteren als dit eenmaal voldoende is. Als een pagina 10.000x getoond wordt voer je 10.000 keer de "conversie" uit en dat is onzin als je met wat extra storage die conversie gewoon kunt opslaan ("cachen"). Beter wat storage opofferen dan CPU cycles. Een extra/grotere HD is zo bijgeprikt, een extra CPU/Server is meer ellende

Alleen bij edits dien je opnieuw die "conversie" uit te voeren. Zo moeilijk ("bug gevoelig") is dat niet, omdat je het in principe maar op 1 plaats hoeft te "vangen"; namelijk zodra er iets naar de DB geschreven wordt (insert/update).

Die "corruptie" problemen heb je net zo goed als je maar 1 van de 2 mogelijkheden (UBB/HTML) zou opslaan. Tabel corrupt = tabel corrupt en niet het ene veldje wel en het andere niet.

Zelf GoT doet het op deze manier trouwens

[ Voor 25% gewijzigd door RobIII op 24-08-2006 19:49 ]

[Anoniem: 162148]

JeRa schreef op donderdag 24 augustus 2006 @ 19:37:
Ik stel een extra optie voor: sla zowel de broncode als het geparsede resultaat op in de database.

Nadeel: meer ruimte benodigt in de database.
Voordeel: niet meer de in de OP genoemde problemen

Daar zat ik vandaag ook aan te denken, is misschien de beste optie.

[aex351]

RobIII schreef op donderdag 24 augustus 2006 @ 19:44:
[...]

Dubbele data ja, maar wel het beste van 2 werelden. Ten eerste is het onzin om bij iedere view het bericht opnieuw van UBB->HTML te converteren als dit eenmaal voldoende is. Als een pagina 10.000x getoond wordt voer je 10.000 keer de "conversie" uit en dat is onzin als je met wat extra storage die conversie gewoon kunt opslaan ("cachen"). Beter wat storage opofferen dan CPU cycles. Alleen bij edits dien je opnieuw die "conversie" uit te voeren. Die "corruptie" problemen heb je net zo goed als je maar 1 van de 2 mogelijkheden (UBB/HTML) zou opslaan. Tabel corrupt = tabel corrupt en niet het ene veldje wel en het andere niet.

Zelf GoT doet het op deze manier trouwens

Ja maar Cachen is wat anders dan het direct naast BB code op te slaan.

[RobIII]

aex351 schreef op donderdag 24 augustus 2006 @ 19:49:
[...]

Ja maar Cachen is wat anders dan het direct naast BB code op te slaan.

Het staat niet voor niets tussen quotes, en in principe is dit gewoon cachen, want je slaat het resultaat op zodat je het de volgende keer niet nog eens hoeft te "berekenen" (lees: converteren)

[aex351]

Dat begrijp ik dat wanneer je het cached het niet nog een keer hoeft te converteren. Maar je moet ook afvragen hoeveel impact het cachen heeft vs converteren. Cachen hoeft niet persee altijd de beste oplossing te wezen.

[lennartkocken]

Je zou er natuurlijk ook voor kunnen kiezen dat een bericht maximaal een half uur aanpasbaar is, en dat je elke nacht (cronjob) de BBCode in de database omzet tot html. Dan heb je ook geen last meer van dat als iemand het wil bewerken, want dat mag dan allang niet meer, en ook niet van de lange laadtijd bij het converteren van BBCode naar html

[Anoniem: 162148]

Ik wil gewoon weten waarom het geen goed idee is, om het dmv Javascript functie te doen, zo wordt jouw server niet belast, en je hoeft niks te cachen.

[lennartkocken]

maar toen had iemand Javascript uitstaan??

[Anoniem: 26306]

Anoniem: 162148 schreef op donderdag 24 augustus 2006 @ 20:11:
Ik wil gewoon weten waarom het geen goed idee is, om het dmv Javascript functie te doen, zo wordt jouw server niet belast, en je hoeft niks te cachen.

Omdat javascript weleens uitgeschakeld kan zijn. Omdat een user agent misschien helemaal geen javascript ondersteunt. Omdat zoekmachines je inhoud niet kunnen indexeren.

Dus eigenlijk om dezelfde reden waarom je XML transformaties niet client-side moet doen, plus nog wat meer.

[Japidoff]

en hoe wil je dat doen in js dan?
bij elke pagina die je verstuurd een bonk Javascript meesturen om de eventueel aanwezige BB code te converteren?
of is ik iets?

[ Voor 4% gewijzigd door Japidoff op 24-08-2006 20:23 ]

[FragFrog]

Beetje dubbel, maar gebruik gewoon een template parser met caching zoals Smarty en het hele probleem verdwijnt als sneeuw voor de zon

* FragFrog zelf ook gedaan voor de comments op blog.fragfrog.nl

Tip: als je zelf de conversie schrijft verdomde goed op je regexen letten bij dingen als een img of url conversie waarin je direct een string tekst (de url) gebruikt in je output. Was zelf op een gegeven moment aanhalingsteken vergeten, met als nare gevolg dat iemand javascript kon uitvoeren (de andere coder aan het project had een paar uurtjes met een security expert exploits zitten zoeken ).

//edit
Grom, lees niet goed, TS is tegen caching. Erm, behalve dat mensen zonder JS alleen een vern**kte versie van je content zien en je elke keer weer die brok JS mee moet sturen is er niet zo heel veel op tegen (search engines kijken toch niet naar UBB code ), maar ik zou het de moeite niet waard vinden eigenlijk. Je kan met een paar regexen de ~ 20 ofzo meest gebruikte UBB codes laten converteren, daar wordt je pagina echt niet (veel) langzamer van. Verreweg de meeste tijd gaat toch zitten in je SQL querys gok ik, dus mocht je echt performance-problemen hebben is het alsnog een beter idee om je volledige pagina's te gaan cachen.

[ Voor 34% gewijzigd door FragFrog op 25-08-2006 00:35 ]

[NMe]

FragFrog schreef op vrijdag 25 augustus 2006 @ 00:28:
Beetje dubbel, maar gebruik gewoon een template parser met caching zoals Smarty en het hele probleem verdwijnt als sneeuw voor de zon

* FragFrog zelf ook gedaan voor de comments op blog.fragfrog.nl

offtopic:
En waarom zou dat zonder losse template parser niet kunnen? Net alsof je zonder logge templatecode geen cache kan aanleggen.

[prototype]

Vraag jezelf eerst eens af OF je hoeft te optimaliseren; ga eerst even profilen of het dus uberhaupt wel nodig is. Zo nee, begin er dan ook niet (voorbarig) aan. Scheelt je tijd dat je kan besteden aan andere leuke dingen, zoals eendjes voeren enzo.
Mocht het nodig zijn, dan zijn er al een aantal alternatieven aangedragen. Persoonlijk heb ik wat bezwaar tegen het dubbel opslaan, niet zozeer met cachen, maar eerder met cachen in je database. Hier zijn een aantal dingen op aan te merken. RobIII beweert dat het een kwestie is van een simpele hdd uitbreiding om mee te schalen, maar dat is niet geheel correct. De consequenties zijn o.a. dat je post database praktisch 2x in omvang wordt; ook al heb je te maken met een relationele database, een database die met steeds meer moet werken zal op den duur minder performen, om maar te zwijgen over de redundancy in je datamodel; je moet jezelf afvragen of je die shit uberhaupt wel persistent wil opslaan.
Object caching is een betere oplossing hiervoor, waarbij je dus wegschrijft naar je hdd maar in volatile memory dus een swaptable bijhoudt, wat snel genoeg gaat (understatement). Een voorbeeld hiervan is http://www.danga.com/memcached/, die oorspronkelijk voor livejournal was ontwikkeld en als een daemon draait. Check die site maar voor meer informatie.

[Anoniem: 184762]

Inderdaad. Ik zou pas iets met memcached gaan doen als de performance echt onvoldoende is. String processing is vrij snel, door de hoge mate van spatial locality. Zodra die eerste byte van de string een cache miss oplevert laadt ie de complete cacheline in en veroorzaakt dus gemiddeld geen enkele opeenvolgende lookup een cache miss (binnen de grootte van de cacheline). Dit is heel erg snel.

First law of profiling and optimalisation: 90% of the execution time is spent in 10% of the code, and it's not the 10% you think it is.

[ Voor 52% gewijzigd door Anoniem: 184762 op 25-08-2006 02:04 ]

[prototype]

Ter aanvulling op Mauritsd dus:
Het voordeel van deze manier van cachen dus is dat je niet per definitie ALLES cached, maar slechts die dingen die gecached DIENEN te worden ook daadwerkelijk cached, of een grotere waarschijnlijkheid hebben om vaker dan 1 maal bekeken te worden. Het verbaast me dan ook dat react in database cached... ik bedoel, HEEL VEEL topics op dit forum worden echt niet meer of nauwelijks bekeken....

[RobIII]

prototype schreef op vrijdag 25 augustus 2006 @ 01:48:
Ter aanvulling op Mauritsd dus:
Het voordeel van deze manier van cachen dus is dat je niet per definitie ALLES cached, maar slechts die dingen die gecached DIENEN te worden ook daadwerkelijk cached, of een grotere waarschijnlijkheid hebben om vaker dan 1 maal bekeken te worden. Het verbaast me dan ook dat react in database cached... ik bedoel, HEEL VEEL topics op dit forum worden echt niet meer of nauwelijks bekeken....

Ten eerste kun je die "cache" natuurlijk op een andere schijf opslaan dan de rest van de gegevens (om de performance-draw zo goed als 0,0 te maken), ten tweede heb je een boel minder potentiële 'zwakke schakels' in je code dan de manier die jij voorstelt (met deamons die ermee kunnen kappen etc.) en ten derde is het puur byteneukerij. Trust me, ik ben zelf als devver altijd erg spaarzaam met opslagruimte en memory allocations (zeker omdat ik nog uit de 16k en zelfs 8k tijd stam ), maar dit is typisch een geval van niet lullen maar devven

Je kunt uren/dagen/weken spenderen aan allerlei (al dan niet) complexe caching methodes, maar simpelweg uitvoeren op de manier zoals ik hier beschrijf is in no time ge-code en kost je (bijna) alleen maar extra schijfruimte. Knal er 100/200/500 euro tegen aan voor wat extra (veel) schijfcapaciteit (mocht je uberhaupt te kort komen) en je bent er. Een devver kost al gauw meer na een paar uren/dagen devven
Qua performance-draw is het sowieso al amper tot niet merkbaar/meetbaar als je (bijv) de "cache" plaatst op een andere schijf dan de rest van de DB (andere filegroup) en qua indexes en read/write/zoekperformantie maakt het geen reet uit (text/blob/memo fields zijn enkel pointers naar de werkelijke data in de eigenlijke tabel die verwijzen naar de data aan het eind/andere tabel/file). Dat kost je doorgaans maar een byte of 16 en die past makkelijk in de pipelines/caches/busses van je CPU bij de rest van je record(s). En dan heb ik het nog niet eens alleen maar over caches op CPU niveau maar ook op schijfniveau, memory busses etc. Die bytes vliegen net zo vrolijk mee zonder (al te veel/meetbare) "kosten".

[ Voor 12% gewijzigd door RobIII op 25-08-2006 02:36 ]

[Gomez12]

prototype schreef op vrijdag 25 augustus 2006 @ 01:48:
Ter aanvulling op Mauritsd dus:
Het voordeel van deze manier van cachen dus is dat je niet per definitie ALLES cached, maar slechts die dingen die gecached DIENEN te worden ook daadwerkelijk cached, of een grotere waarschijnlijkheid hebben om vaker dan 1 maal bekeken te worden. Het verbaast me dan ook dat react in database cached... ik bedoel, HEEL VEEL topics op dit forum worden echt niet meer of nauwelijks bekeken....

Dit gaat op voor "snel" cachen ( memory etc ) waar ruimte spaars is. Maar als ruimte genoeg aanwezig is ( hdd ) dan is het gewoon pure performance winst doordat je de hele conversie slag overslaat.
Is je ruimte niet oneindig dan zou je nog kunnen denken aan een cronjob die 1x per week al je oude html weggooit en bij pageviews eerst de html aanspreekt, bestaat deze niet dan wordt deze ter plekke aangemaakt. Kost je relatief weinig ruimte tegenover veel voordeel. ( Relatief weinig ruimte omdat je voor een appel en een ei een 40GB hdd kunt kopen en hier heel makkelijk een lange tijd mee vooruit kan, of vul jij 20GB met tekst / ubb codes in een week??? )

Heel simpel gesteld.
Meest onvoordelige situatie :
UBB Code in dbase

code:

Bezoeker vraagt webpagina op.
Webserver vraagt webpagina inhoud op bij dbaseserver
Webserver decodeert dbaseantwoord naar html voor bezoeker
Bezoeker krijgt pagina

Html Code in dbase

code:

Bezoeker vraagt webpagina op.
Webserver vraagt webpagina inhoud op bij dbaseserver
Bezoeker krijgt pagina

Dit is al 25% performance winst tegenover een beetje schijfruimte.

Gebruik nu voor je meest aangeroepen topics nog een memory caching systeem en je hebt 2 van de 4 stappen voorkomen bij een veel opgevraagd topic.
Terwijl je alle flexibiliteit behoud van de ubb codes. Als je het een beetje goed opzet ( indien geen html aanwezig dan ter plekke aanmaken ) kan je zelfs je ubb->html converter omschrijven en door de html-tabel leeg te halen krijgt na de 1e aanroep iedereen elke pagina snel en correct geserveerd terwijl je altijd de bron blijft behouden.
Je wilt xhtml 3.0 serveren ipv html 1.0 dan is het alleen een kwestie van je ubb->html converter omschrijven zodat deze xhtml serveert en je html-tabel leeggooien. Je hebt het gemak alsof je alleen maar UBB in je dbase hebt staan, terwijl je de snelheid hebt van pure html...
Best of 2 worlds tegen de kosten van een beetje schijfruimte...

[RobIII]

Gomez12 schreef op vrijdag 25 augustus 2006 @ 03:47:
Dit is al 25% performance winst tegenover een beetje schijfruimte.

Die 25% is gebaseerd op??...

[prototype]

RobIII schreef op vrijdag 25 augustus 2006 @ 02:22:
[...]

Ten eerste kun je die "cache" natuurlijk op een andere schijf opslaan dan de rest van de gegevens (om de performance-draw zo goed als 0,0 te maken), ten tweede heb je een boel minder potentiële 'zwakke schakels' in je code dan de manier die jij voorstelt (met deamons die ermee kunnen kappen etc.) en ten derde is het puur byteneukerij. Trust me, ik ben zelf als devver altijd erg spaarzaam met opslagruimte en memory allocations (zeker omdat ik nog uit de 16k en zelfs 8k tijd stam ), maar dit is typisch een geval van niet lullen maar devven

De manier die je beschrijft zal vast wel bijdragen aan een loadverbetering, maar praktisch is het niet, zeker als je het een beetje betrouwbaar wil, meerdere raid sets etc... De daemon is wel een extra schakel, maar wel eentje die je in een later stadium erin kan zetten en ook eruit kan halen, i.e. wanneer het ook nodig is (en dat moet je eerst vaststellen voordat je overgaat tot een van de genoemde praktijken binnen deze topic!) Bij de memcached oplossing kan je dit iig realiseren zonder je datamodel hiervoor aan te moeten passen, en je krijgt hier behoorlijke performance winst voor terug zoals mauritsd beschreef, die naar alle waarschijnlijkheid sneller is dan het 'cached' opslaan in de db. Het enige wat gezegd kan worden over de daemon is dat het een extra schakel vormt, maar niet een minder dan de extra hdd waar je het over hebt; feit blijft dat alles de potentie heeft om onderuit te gaan.
In jouw tijd zou de motto vast niet lullen maar devven zijn geweest, maar in mijn tijd ging het iig om common sense[tm].

Je kunt uren/dagen/weken spenderen aan allerlei (al dan niet) complexe caching methodes, maar simpelweg uitvoeren op de manier zoals ik hier beschrijf is in no time ge-code en kost je (bijna) alleen maar extra schijfruimte. Knal er 100/200/500 euro tegen aan voor wat extra (veel) schijfcapaciteit (mocht je uberhaupt te kort komen) en je bent er. Een devver kost al gauw meer na een paar uren/dagen devven

Er zijn echt heel veel memcached api's voorhanden, ook voor php. Het is dan echt een kwestie van een paar regels, en je spreekt dan eerder in dit geval over minuten dan over uren/dagen/weken. Je krijgt hiervoor binnen no-time een oplossing die eleganter is (datamodel hoeft niet aangepast te worden en memcache kan geimplementeerd worden waar en wanneer dat ook nodig is, op een doodeenvoudige manier), minder of evenveel hdd ruimte nodig heeft dan jouw oplossing en daarbovenop (veel) beter performed. Bovendien is het toepasbaar op alle data en niet zozeer op alleen voor "cached ubb code". Ik weet wel wat ik zou willen wanneer de nood hoog zou zijn.

Qua performance-draw is het sowieso al amper tot niet merkbaar/meetbaar als je (bijv) de "cache" plaatst op een andere schijf dan de rest van de DB (andere filegroup) en qua indexes en read/write/zoekperformantie maakt het geen reet uit (text/blob/memo fields zijn enkel pointers naar de werkelijke data in de eigenlijke tabel die verwijzen naar de data aan het eind/andere tabel/file). Dat kost je doorgaans maar een byte of 16 en die past makkelijk in de pipelines/caches/busses van je CPU bij de rest van je record(s). En dan heb ik het nog niet eens alleen maar over caches op CPU niveau maar ook op schijfniveau, memory busses etc. Die bytes vliegen net zo vrolijk mee zonder (al te veel/meetbare) "kosten".

Het is afhankelijk van de sitautie om uitspraken te doen hierover, en aangezien die ontbreken zal ik afsluiten met dat het vast wel bij zal dragen maar praktisch is het imho niet, zoals eerder gezegd.

[chris]

Ik had een heel cool systeem, waarbij mijn ubb-code-omzetter compleet in regexes was gebouwd.Het leuke hiervan was dat je deze zowel op de server als op de client kon gebruiken (Javascript doet hier ook aan). Wat ik dus had was een live-preview op de client, maar wel de veiligheid van parsen op de server (users kunnen geen rare HTML posten).

[FragFrog]

-NMe- schreef op vrijdag 25 augustus 2006 @ 01:25:

offtopic:
En waarom zou dat zonder losse template parser niet kunnen? Net alsof je zonder logge templatecode geen cache kan aanleggen.

offtopic:
Het was een voorbeeld, voortgekomen uit persoonlijke ervaring met wat goed werkt Over het nut van template parsers hebben we het geloof ik al eens gehad, geen zin die discussie weer met je te voeren hier en nu