WYSIWYG editor voor userreviews (en misch. in het algemeen)

[SizzLorr]

Ik weet niet wat de meester reviewers op tweakers ervan vinden, maar ik had het genoegen om voor het Testfest een userreview te schrijven en met de huidige editor was dat een hell!
productreview: LG Q6 Zwart review door SizzLorr

Ik had sowieso dit probleem:
SizzLorr in "Tweakers Oktober Testfest"

Maar een algemeen probleem is dat de huidige editor is verouderd en absoluut niet geschikt voor grote reviews met gevorderde opmaak.

Het begint al met dat je zelf handmatig UBB codes moet invoeren. Het is veel werk, maar het lukt nog wel. Dat kan ik nog door de vingers zien.

De problemen beginnen tijdens het reviseren en proofreaden. Als je iets wil aanpassen dan, moet je onthouden waar het is, terug naar boven scrollen en op aanpassen klikken. Dan kom op een andere pagina met de editor in een combox waar rauwe opmaak in staat, zoeken naar de plek, veel scrollen, aanpassen en opslaan. Dan ga je weer terug naar de vorige pagina waar je weer terug naar beneden moet scrollen op zoek naar de plek en hopen dat alles goed gaat.

Dit alles wordt nog erger als je aan het experimenteren bent met opmaak als lijstjes, tabellen en sierfoto's. Uiteindelijk heb ik mijn tabellen gegenereerd met deze tool en de UBB code over gekopieerd.
https://www.teamopolis.com/tools/bbcode-table-generator.aspx

Het zou sowieso handig zijn als je op een knopje had of (Marktplaats stijl) kan dubbelklikken op de tekst zodat je direct de editor voor je neus krijgt op die locatie.

Daarnaast zou ik het ook handig vinden als je foto's direct kan uploaden naar je galerij of vanuit je galerij foto's en thumbnails kan invoegen.

Het kan ook zijn dat het aan mij ligt hoor. Academisch achtergrond, dus ik ben gewend om eerst iets te schrijven en dat te reviseren tot het goed is. Als je zo'n werkmethode wil aanhouden met de huidige editor, is gewoon niet te doen. Zover zelfs dat ik uiteindelijk ben gestopt met corrigeren van taalvoutjes. Ik werd net weer gewezen op een taalvoutje en ik heb er gewoon helemaal geen zin in, teveel gedoe.

Hoelang gebruikt tweakers de huidige editor? Misschien tijd voor iets nieuws. Ik verwacht dat de kwaliteit van reviews omhoog zal gaan als de editor wordt verbetert.

[Voor 5% gewijzigd door SizzLorr op 26-10-2017 06:45]

[unezra]

WYSYSIG lijkt mij ook wel fijn. Juist ook in het forum.
(Maar dan wel optioneel, kan me voorstellen dat veel mensen het ook fijn vinden om code te typen.)

[SizzLorr]

Voor in het forum voor een topicstart kan ik me voorstellen dat het daar ook nuttig is. Voor de gewone discussies en replies zou ik idd aanhouden wat er nu is want dat hoeft helemaal niet zo fancy te zijn.

[418O2]

unezra schreef op donderdag 26 oktober 2017 @ 07:26:
WYSYSIG lijkt mij ook wel fijn. Juist ook in het forum.
(Maar dan wel optioneel, kan me voorstellen dat veel mensen het ook fijn vinden om code te typen.)

Wysiwig werkt niet, is niet handig met variables breedtes en een hel om veilig op te slaan en te parsen.

Ik zie dit niet gebeuren. Misschien iets als markdown, maar wysiwig niet

[Voor 5% gewijzigd door 418O2 op 26-10-2017 18:29]

[unezra]

418O2 schreef op donderdag 26 oktober 2017 @ 18:29:
[...]

Wysiwig werkt niet, is niet handig met variables breedtes en een hel om veilig op te slaan en te parsen.

Ik zie dit niet gebeuren. Misschien iets als markdown, maar wysiwig niet

Mwah. Ik werk regelmatig met de WYSIWYG editor in Dokuwiki en dat werkt verrassend goed. Maar ik denk ook dat het optioneel moet zijn, niet verplicht.

[Hero of Time]

unezra schreef op donderdag 26 oktober 2017 @ 19:30:
[...]

Mwah. Ik werk regelmatig met de WYSIWYG editor in Dokuwiki en dat werkt verrassend goed. Maar ik denk ook dat het optioneel moet zijn, niet verplicht.

Hebben ze eindelijk die editor fatsoenlijk aan de praat gekregen? Heb 't jaren geleden eens toegevoegd aan onze Dokuwiki die ik had opgezet en het werd regelmatig helemaal overhoop gegooid. Schakelen van wysiwyg naar de standaard editor zorgde voor een gewijzigde pagina (zonder iets te hebben aangepast) met extra witregels en mooie uitlijningen in tabellen om het ook in plain text leesbaar te hebben werd een grote rotzooi.

Er is al eerder gesproken over het maken van een wysiwyg editor voor Tweakers. Je zit met ubb-code die fatsoenlijk geparsed moet kunnen worden. Stel nou dat ik een bericht met de standaard editor die we nu hebben maak, met een quote erin waarbij ik de korte tag gebruik en ook met de korte methode sluit (dat is [q] en [/] voor wie deze niet kent). Dan moet de editor dit ook netjes aan kunnen. Nu al zijn er tags die je in tags kan gebruiken waarbij het gebruiken van de korte sluit tag tot problemen kan leiden. Een wysiwyg moet hier ook mee overweg kunnen.

Dan heb je ook nog dat het alle tags moet ondersteunen en aanbieden. Wat als we nou nieuwe tags krijgen, stel een [twitter] tag om tweets te embedden zoals we dat met video's en plaatjes kunnen?

Het oorspronkelijke verzoek hier is om het schrijven van reviews beter te maken. Een eerste stap is om alle tags die we hebben te ondersteunen. Dat is momenteel helaas niet zo. Een volgende stap kan de preview verbeteren zijn. Het is nu nogal omslachtig IMO.

Beginnen met kleine stapjes.

[crisp]

Als we wysiwyg willen overwegen moeten we simpelweg afstappen van UBB/RML en puur HTML gaan faciliteren met een strenge cleanup-parser op de back-end. Echter is het ueberhaupt goed instellen van een wysiwyg editor ook geen sinecure. We zijn op dit moment bezig met een nieuwe wysiwyg editor voor de redactie (die altijd al HTML hebben gebruikt) en uit dat project blijkt ook weer hoe lastig het is, en specifieke requirements maken ook dat het dan alleen maar werkt in de laatste versies van browsers (en niet in IE/Edge).

Verder wil je (redacteuren, maar zeker gebruikers) ook niet teveel mogelijkheden geven. Niet alleen levert dat een potpourri op van (slechte) style-kenmerken en inconsistenties, maar het maakt het ook behoorlijk lastig om content responsive te presenteren en bij aanpassingen moet je vaak weer allerlei dingen in de content converteren met alle risico's van dien.

Ik denk dat het goed is als er eens gedegen onderzocht wordt wat mensen vooral nodig hebben, en dan pas te kijken naar tooling om dat te ondersteunen

[SizzLorr]

418O2 schreef op donderdag 26 oktober 2017 @ 18:29:
[...]

Wysiwig werkt niet, is niet handig met variables breedtes en een hel om veilig op te slaan en te parsen.

Ik zie dit niet gebeuren. Misschien iets als markdown, maar wysiwig niet

Kijk eens naar TinyMCE, ORY Editor, HTML Editor, Redactor, Station of een van de vele andere betaalde of opensource alternatieven. Als je de stylesheet van de site goed in elkaar zet en dat ook doorvoert naar de editor is het geen probleem.

Grappig dat je begint over breedtes en marges, want in de TS geef ik zelf al aan dat er een probleem is met de huidige CSS icm UBB code en marges.

crisp schreef op donderdag 26 oktober 2017 @ 21:01:
Als we wysiwyg willen overwegen moeten we simpelweg afstappen van UBB/RML en puur HTML gaan faciliteren met een strenge cleanup-parser op de back-end. Echter is het ueberhaupt goed instellen van een wysiwyg editor ook geen sinecure. We zijn op dit moment bezig met een nieuwe wysiwyg editor voor de redactie (die altijd al HTML hebben gebruikt) en uit dat project blijkt ook weer hoe lastig het is, en specifieke requirements maken ook dat het dan alleen maar werkt in de laatste versies van browsers (en niet in IE/Edge).

Verder wil je (redacteuren, maar zeker gebruikers) ook niet teveel mogelijkheden geven. Niet alleen levert dat een potpourri op van (slechte) style-kenmerken en inconsistenties, maar het maakt het ook behoorlijk lastig om content responsive te presenteren en bij aanpassingen moet je vaak weer allerlei dingen in de content converteren met alle risico's van dien.

Ik denk dat het goed is als er eens gedegen onderzocht wordt wat mensen vooral nodig hebben, en dan pas te kijken naar tooling om dat te ondersteunen

Er zijn genoeg editors die ook UBB ondersteunen. De vraag is ook niet om meer functionaliteit te geven qua codes maar om het makkelijker te maken om grote reviews in te voeren. Het voorbeeld van dat je echt veel moeite moet doen om iets te reviseren of corrigeren is het voorbeeld om in gedachten te houden. Dit is de opmaak van de review waar ik naar link, ergens midden in zitten nog een paar taalvoutjes. Copy/paste de code naar een combobox, succes!

code:

[Voor 147% gewijzigd door SizzLorr op 27-10-2017 03:34]

[Hero of Time]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 03:27:
Copy/paste de code naar een combobox, succes!

Waarom heb je het telkens over een combobox? Daar kan je echt niets bij invullen, het bevat waardes die al voorgedefinieerd zijn. Zie ook Wikipedia: Combo box. Je bedoelt een multi-line input veld, wat de reactievelden hier zijn en wat je dus gebruikt om een review te schrijven.

[crisp]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 03:27:
[...]


Kijk eens naar TinyMCE, ORY Editor, HTML Editor, Redactor, Station of een van de vele andere betaalde of opensource alternatieven. Als je de stylesheet van de site goed in elkaar zet en dat ook doorvoert naar de editor is het geen probleem.

We zijn net aan het afstappen van TinyMCE; dat is echt een gedrocht geworden

[...]

Er zijn genoeg editors die ook UBB ondersteunen.

Vanilla UBB wel ja, maar niet onze variant met geavanceerde features als short-close tags, empty elements, zowel komma-separated als name-value attribute style etc. Daarbij is het behoorlijk inefficiënt als je zowel server- als clientside heen en weer moet gaan parsen.

De vraag is ook niet om meer functionaliteit te geven qua codes maar om het makkelijker te maken om grote reviews in te voeren. Het voorbeeld van dat je echt veel moeite moet doen om iets te reviseren of corrigeren is het voorbeeld om in gedachten te houden. Dit is de opmaak van de review waar ik naar link, ergens midden in zitten nog een paar taalvoutjes. Copy/paste de code naar een combobox, succes!

[...]

De grootste fout die je maakt is dat je tabellen misbruikt voor opmaak. Dat zorgt voor veel clutter van opmaakcodes wat het inderdaad lastig maakt om te redigeren. Daarbij zijn tabellen ook notoir lastig om responsive goed te krijgen. Daar zit waarschijnlijk dan ook het probleem met de breedtes en marges. Als je gewoon een nette structuur gebruikt met headings, paragrafen en hier en daar een mooi plaatje dan kan je je inhoudsopgave ook makkelijk automatisch laten genereren met de [toc]-tag

Wat ik daarnaast vooral zie is is dat het ook heel erg veel tekst is waarbij het wellicht handiger is om dat, in ieder geval aan de beheerkant, te pagineren. Dat is ook hoe onze redacteuren reviews beheren.

[SizzLorr]

Hero of Time schreef op vrijdag 27 oktober 2017 @ 07:55:
[...]

Waarom heb je het telkens over een combobox? Daar kan je echt niets bij invullen, het bevat waardes die al voorgedefinieerd zijn. Zie ook Wikipedia: Combo box. Je bedoelt een multi-line input veld, wat de reactievelden hier zijn en wat je dus gebruikt om een review te schrijven.

Ik ben blij dat er mensen zijn die zijn afgestudeerd op comboboxes. Tekstvalk, ding waar je tekst in kan voeren... geef het beestje een naampje.

crisp schreef op vrijdag 27 oktober 2017 @ 08:17:

De grootste fout die je maakt is dat je tabellen misbruikt voor opmaak. Dat zorgt voor veel clutter van opmaakcodes wat het inderdaad lastig maakt om te redigeren. Daarbij zijn tabellen ook notoir lastig om responsive goed te krijgen. Daar zit waarschijnlijk dan ook het probleem met de breedtes en marges. Als je gewoon een nette structuur gebruikt met headings, paragrafen en hier en daar een mooi plaatje dan kan je je inhoudsopgave ook makkelijk automatisch laten genereren met de [toc]-tag

Wat ik daarnaast vooral zie is is dat het ook heel erg veel tekst is waarbij het wellicht handiger is om dat, in ieder geval aan de beheerkant, te pagineren. Dat is ook hoe onze redacteuren reviews beheren.

Ok dan haal ik dat weg voor je en ga ik header tags gebruiken... Je begrijpt toch wel dat wat ik zeg nog steeds van toepassing is toch? Laat ik maar zo bot zijn... het is gewoon kut met invoeren en reviseren, vooral als je een hoopt tekst in z'n klein kut textboxje krijgt. Dat heeft niks met dit of dat te maken, dat heeft te maken dat het gewoon kut geregeld is. Als je iets midden in de tekst wil aanpassen, dan moet je onthouden waar het is, terug naar boven scrollen, op aanpassen klikken, door een hoop tekst scrollen opzoek naar de plek, aanpassen, opslaan en weer terug naar beneden scrollen naar dezelfde plek. Dat kan toch beter man!

[crisp]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 11:28:
[...]


Ik ben blij dat er mensen zijn die zijn afgestudeerd op comboboxes. Tekstvalk, ding waar je tekst in kan voeren... geef het beestje een naampje.

In html is het een <textarea> dus 'tekstv(l)ak' lijkt me inderdaad een goede benaming

Dat kan toch beter man!

Ik geef in mijn laatste zin ook aan waar dat volgens mij al beter kan. Wysiwyg gaat je niet echt veel beter helpen bij veel content; dan moet je ook gaan scrollen en zoeken. Het is dan beter om het bijvoorbeeld per hoofdstuk te kunnen bekijken en editten. Scructuur aanbrengen dus, en niet het ene tekstv(l)ak inruilen voor een iets meer fancy tekstv(l)ak

[Voor 35% gewijzigd door crisp op 27-10-2017 11:35]

[SizzLorr]

crisp schreef op vrijdag 27 oktober 2017 @ 11:31:
[...]
In html is het een <textarea> dus 'tekstv(l)ak' lijkt me inderdaad een goede benaming

Is dit nou echt reply waardig? In een of andere gare c++ framework heet het een combobox overigens dus het is maar hoe je het wil noemen, zijn we het erover uit dat het gaat om het vlak waar je tekst in moet voeren?

[Voor 29% gewijzigd door SizzLorr op 27-10-2017 11:37]

[418O2]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 03:27:
[...]


Kijk eens naar TinyMCE, ORY Editor, HTML Editor, Redactor, Station of een van de vele andere betaalde of opensource alternatieven. Als je de stylesheet van de site goed in elkaar zet en dat ook doorvoert naar de editor is het geen probleem.

Grappig dat je begint over breedtes en marges, want in de TS geef ik zelf al aan dat er een probleem is met de huidige CSS icm UBB code en marges.

Ik verdien mijn geld met front-end development, maar wysiwig is een illusie. Het is gewoon heel moeilijk om gebruikers vrijheid te geven zonder dat ze dingen stuk kunnen maken...

[SizzLorr]

418O2 schreef op vrijdag 27 oktober 2017 @ 11:43:
[...]

Ik verdien mijn geld met front-end development, maar wysiwig is een illusie. Ik vind het gewoon heel moeilijk om gebruikers vrijheid te geven zonder dat ze dingen stuk kunnen maken...

Je zegt het verkeerd, ik heb het voor je gecorrigeerd.

[418O2]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 11:45:
[...]


Je zegt het verkeerd, ik heb het voor je gecorrigeerd.

Het is wel goed met je.

[SizzLorr]

418O2 schreef op vrijdag 27 oktober 2017 @ 11:46:
[...]

Het is wel goed met je.

Njah luister eens, je zegt wysiwyg werkt niet omdat het moeilijk is om gebruikers vrijheid te geven. Als je er even over nadenkt dan heeft dat niks met wysiwyg of een editor of wat dan ook te maken, het heeft te maken met jou implementatie. Ik kan er niks anders van maken, sorry.

[418O2]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 11:49:
[...]


Njah luister eens, je zegt wysiwyg werkt niet omdat het moeilijk is om gebruikers vrijheid te geven. Als je er even over nadenkt dan heeft dat niks met wysiwyg of een editor of wat dan ook te maken, het heeft te maken met jou implementatie. Ik kan er niks anders van maken, sorry.

Ik hoop dat je zelf inziet dat deze manier van discussieren je niets gaat brengen.

[SizzLorr]

418O2 schreef op vrijdag 27 oktober 2017 @ 11:50:
[...]

Ik hoop dat je zelf inziet dat deze manier van discussieren je niets gaat brengen.

Ik hoop dat jij inziet dat je met iets betere argumenten moet komen als "ik verdien mijn geld ermee". En dan ben ik zo'n klootzakje die zoiets leest en eerst jou argumentum ad verecundiam en daarop volgend een raar argument ziet waar ik toch zeer kritisch over ben. Je zegt wysiwyg is lastig want vrijheid, maar uit het ene volgt het andere niet dus is het moeilijk voor mij om het verband te zien.

Dan is dit het internet (welkom) en zijn er mensen zoals ik die keihard andere mensen callen op dit soort dingen, als je dat niet kan hebben, tja, zet je PC uit en ga lekker buiten spelen. Sorry dat ik jou autoriteit niet erken.

[Voor 50% gewijzigd door SizzLorr op 27-10-2017 12:02]

[418O2]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 11:51:
[...]


Ik hoop dat jij inziet dat je met iets betere argumenten moet komen als "ik verdien mijn geld ermee". En dan ben ik zo'n klootzakje die zoiets leest en eerst jou argumentum ad verecundiam en daarop volgend een raar argument ziet waar ik toch zeer kritisch over ben. Je zegt wysiwyg is lastig want vrijheid, maar uit het ene volgt het andere niet dus is het moeilijk voor mij om het verband te zien.

Dan is dit het internet (welkom) en zijn er mensen zoals ik die keihard andere mensen callen op dit soort dingen, als je dat niet kan hebben, tja, zet je PC uit en ga lekker buiten spelen. Sorry dat ik jou autoriteit niet erken.

Dan lees jij creatief; ik geef alleen aan dat ik er professionele ervaring mee heb. Dus niet dat je denkt dat ik een hobbyist ben die een keer wat heeft gelezen.

Ik wil best een discussie met je voeren, maar niet op deze manier. Als het makkelijk toe te voegen was, had men het allang gedaan. Het is al vaker geopperd, maar editors zijn gewoon erg moeilijk te bouwen. En als je te maken hebt een responsive site, dan wordt het gewoon erg lastig op daadwerkelijk WYSIWIG voorelkaar te krijgen, omdat je met die breedtes zit. En de meeste editors genereren nogal vieze html als je het mij vraagt.

En dan is het veiligheidsaspect ook nog een ding, want je wil geen loopholes of injects krijgen.

[Voor 5% gewijzigd door 418O2 op 27-10-2017 15:03]

[SizzLorr]

418O2 schreef op vrijdag 27 oktober 2017 @ 15:03:
[...]

Dan lees jij creatief; ik geef alleen aan dat ik er professionele ervaring mee heb. Dus niet dat je denkt dat ik een hobbyist ben die een keer wat heeft gelezen.

Ik wil best een discussie met je voeren, maar niet op deze manier. Als het makkelijk toe te voegen was, had men het allang gedaan. Het is al vaker geopperd, maar editors zijn gewoon erg moeilijk te bouwen. En als je te maken hebt een responsive site, dan wordt het gewoon erg lastig op daadwerkelijk WYSIWIG voorelkaar te krijgen, omdat je met die breedtes zit. En de meeste editors genereren nogal vieze html als je het mij vraagt.

En dan is het veiligheidsaspect ook nog een ding, want je wil geen loopholes of injects krijgen.

Dus wat je zegt is dat jij het niet voor elkaar krijgt om het veilig te maken dus kunnen we het beter niet doen...

[418O2]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 15:07:
[...]


Dus wat je zegt is dat jij het niet voor elkaar krijgt om het veilig te maken dus kunnen we het beter niet doen...

als we toch gaan smijten met latijnse uitspraken...

Het is lastig. En het gaat niet alleen om veiligheid; wysiwig impliceert dat je krijgt wat je ziet en dat is dus niet per definitie zo. Als mensen rommel uit word gaan plakken, dan gaat het al gauw stuk. En in je preview kan iets prima lijken, maar op bepaalde schermen zal het alsnog stuk gaan.

[SizzLorr]

Uuum ik zou toch even opzoeken wat op de man spelen is want dit is dat niet... just saying.

Anyweg, wat jij zegt is.. dat jij... het niet voor elkaar kan krijgen.. om dit setje tag... om te zetten naar html...

Overzicht van UBB-codes

Een setje tags die nog afgebakend zijn en iets wat nu al gebeurd overigens... jij krijgt het niet voor elkaar om daar een simpele editor voor inelkaar te zetten?

Kijk, ik krijg dat wel voor elkaar, los van het feit dat het niet mijn baan is, dus het is echt een probleem bij jou. Als jij je daardoor zo hard aangevallen voelt dat je een ad hominemetje erbij moet pakken, tja jammer. Als je het zo erg vindt dat ik jou argument er op zo'n manier onderuit haal dan moet je ook niet beginnen met "ik" argumenten om jezelf als een autoriteit vast te stellen.

[Voor 14% gewijzigd door SizzLorr op 27-10-2017 15:31]

[Hero of Time]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 15:16:
Uuum ik zou toch even opzoeken wat op de man spelen is want dit is dat niet... just saying.

Sorry, maar je valt hem toch wel redelijk aan. In mijn ogen is dat op de man spelen. Of hoe je het ook wilt noemen, het is niet netjes.

Anyweg, wat jij zegt is.. dat jij... het niet voor elkaar kan krijgen.. om dit setje tag... om te zetten naar html...

Overzicht van UBB-codes

Een setje tags die nog afgebakend zijn en iets wat nu al gebeurd overigens... jij krijgt het niet voor elkaar om daar een simpele editor voor inelkaar te zetten?

Kijk, ik krijg dat wel voor elkaar, los van het feit dat het niet mijn baan is, dus het is echt een probleem bij jou. Als jij je daardoor zo hard aangevallen voelt dat je een ad hominemetje erbij moet pakken, tja jammer. Als je het zo erg vindt dat ik jou argument er op zo'n manier onderuit haal dan moet je ook niet beginnen met "ik" argumenten om jezelf als een autoriteit vast te stellen.

Leuk dat je 't zo voor elkaar krijgt, maar je mist nog steeds de punten die zijn aangehaald, ook door mij en crisp. Er is te veel anders aan de hele ubb-parser van Tweakers om er een generieke editor voor te gebruiken.

Als je het zo triviaal vindt, staat niets je in de weg om zelf eentje te maken en te geven aan de ontwikkelaars hier.

[SizzLorr]

Hero of Time schreef op vrijdag 27 oktober 2017 @ 15:42:
[...]

Sorry, maar je valt hem toch wel redelijk aan. In mijn ogen is dat op de man spelen. Of hoe je het ook wilt noemen, het is niet netjes.

Nogmaals als je het echt zo erg vindt dat ik zijn "ik" argument er onderuit haal dan moet hij maar niet beginnen met dat. dikke vette pech voor de kabouters. Dat is geen ad hominem, dat is argumentatieleer voor beginners.

Leuk dat je 't zo voor elkaar krijgt, maar je mist nog steeds de punten die zijn aangehaald, ook door mij en crisp. Er is te veel anders aan de hele ubb-parser van Tweakers om er een generieke editor voor te gebruiken.

Als je het zo triviaal vindt, staat niets je in de weg om zelf eentje te maken en te geven aan de ontwikkelaars hier.

Dus wat je zegt is dat je het niet voor elkaar krijgt een simpele table lookup te doen en een paar variabelen in te vullen? Vriend ik wil dat best voor je maken maar dan wil ik er wel voor betaald krijgen. Ik vind het best, voor niks gaat de zon op.

Wat jullie schijnen te missen is dat dat gezeik en gezeur over technische mogelijkheden allemaal onzin is, dat zijn dingen die je in de praktijk toch wel opgelost krijgt, daar heb je immers een duur betaalde devteam voor.

De discussie hier zou moeten zijn over het nut van een editor, niet om de techniek er achter. Dat een paar codemonkeys hier hun l33t sk1llz willen showen, leuk, maar daar heb ikniks aan en het helpt de discussie absoluut niet vooruit. En dan heb ik het weer gedaan!

[Voor 21% gewijzigd door SizzLorr op 27-10-2017 16:07]

[crisp]

SizzLorr schreef op vrijdag 27 oktober 2017 @ 15:56:
[...]

Wat jullie schijnen te missen is dat dat gezeik en gezeur over technische mogelijkheden allemaal onzin is, dat zijn dingen die je in de praktijk toch wel opgelost krijgt, daar heb je immers een duur betaalde devteam voor.

De discussie hier zou moeten zijn over het nut van een editor, niet om de techniek er achter. Dat een paar codemonkeys hier hun l33t sk1llz willen showen, leuk, maar daar heb ikniks aan en het helpt de discussie absoluut niet vooruit. En dan heb ik het weer gedaan!

De discussie over de techniek is in zoverre relevant dat het een indicatie geeft van de complexiteit, en daarmee dus ook van de kosten van een dergelijke feature, en met een 'duurbetaald' devteam kan dat snel oplopen Daarbij is onze capaciteit ook zeer beperkt, dus voor elke featurerequest moet een goede afweging gemaakt worden. Het is dan niet gek om ook te kijken naar mogelijke alternatieven die minder ingewikkeld zijn om te implementeren.

[SizzLorr]

crisp schreef op zaterdag 28 oktober 2017 @ 00:10:
[...]

De discussie over de techniek is in zoverre relevant dat het een indicatie geeft van de complexiteit, en daarmee dus ook van de kosten van een dergelijke feature, en met een 'duurbetaald' devteam kan dat snel oplopen Daarbij is onze capaciteit ook zeer beperkt, dus voor elke featurerequest moet een goede afweging gemaakt worden. Het is dan niet gek om ook te kijken naar mogelijke alternatieven die minder ingewikkeld zijn om te implementeren.

Ik zal het nogmaals en voor de laatste keer herhalen, daar ben ik het absoluut niet mee eens. Is een kwestie van een lookup table die opmaak vertaalt in UBB code, denk dat een stagaire binnen een dag iets werkend heeft. Maar goed, alles is al gezegd.

[crisp]

SizzLorr schreef op zaterdag 28 oktober 2017 @ 00:13:
[...]


Ik zal het nogmaals en voor de laatste keer herhalen, daar ben ik het absoluut niet mee eens. Is een kwestie van een lookup table die opmaak vertaalt in UBB code, denk dat een stagaire binnen een dag iets werkend heeft. Maar goed, alles is al gezegd.

Oh, gewoon zo dus:

PHP:

$ubb = str_replace(['<', '>'], ['[', ']'], $html);

Ik zal het na mijn banaantje meteen implementeren!

[SizzLorr]

Ja wat mij betreft gebruik je een regexp ofzo, weet ik veel, implementatie is een praktisch probleem, dat zoek jezelf maar uit. Vergeet even niet de linebreak en linereturns. Zet er een live preview bij, maak het zodat als je op de livepreview klikt dat je gaat naar de plek waar je op hebt geklikt. Klaar!

Ik zou je wel een tip meegeven. Ik zou kijken naar de aanwezigheid van [] characters, constant de hele html opnieuw parsen is inefficiënt.

Zo moeilijk hoeft het niet te zijn.

[Voor 7% gewijzigd door SizzLorr op 29-10-2017 13:39]

[ACM]

Er zitten een aantal problemen met 'alleen simpele ubb ondersteunen':
- Het is maar de vraag of jouw eigen voorbeeld onder die 'simpele' versie valt en dus of dat specifieke probleem wordt opgelost
- Het is voor gebruikers vreemd dat ze twee manieren van invoeren krijgen en dat ze niet zelf volledige invloed hebben op welke ze krijgen; Bijvoorbeeld, geeft het bewerken van reacties met niet-ondersteunde tags een andere editor dan een met uitsluitend wel-ondersteunde tags?
- Het levert allerlei nieuwe problemen op als de wysiwyg en plain rml editors niet met elkaars output overweg kunnen. Stel bijvoorbeeld dat een gebruiker toch zo'n niet-ondersteunde tag nodig heeft en even switched naar 'text modus' en die toevoegt... dan kan hij daarna niet meer terugswitchen?
Of er moet een complexe hack komen in de editor die op een of andere manier een 'niet ondersteunde' tag kan markeren. Maar wat als er in die niet-ondersteunde tag dan weer wel-ondersteunde tags zitten genest? Moeten al die geneste tags dan ook als 'niet-ondersteund' behandeld worden? Want als die niet-ondersteunde tag invloed heeft op de geneste tags (zoals de norml-tag), zou er een onjuiste voorstelling komen.

En ik mis er vast nog diverse.

Een simpele replace-based versie van zo'n parser gaat doorgaans ook mis doordat het dan invalid html op kan leveren en mede daardoor heel lastig in wysiwyg-vorm is te gieten. Dan kan je beter beginnen met een bestaande editor en kijken hoe je die zo kan inzetten dat het voorgaande problemen zoveel mogelijk vermijdt.

Een wysiwyg editor kan best nuttig zijn, ook omdat er veel duidelijker is wat het effect is van een bepaalde combinatie van tags. Maar het 'makkelijke deel' van onze rml/bbcode implementeren levert helaas ook allerlei problemen op.

SizzLorr schreef op zondag 29 oktober 2017 @ 13:38:
Ik zou je wel een tip meegeven. Ik zou kijken naar de aanwezigheid van [] characters, constant de hele html opnieuw parsen is inefficiënt.

Met een goede tokenizer (die vooraf gaat aan de complexe parser) zal er dan steeds slechts 1 text-token uitkomen als er geen brackets inzitten. Dus die inefficientie is dan in ieder geval al automatisch opgelost

[Voor 11% gewijzigd door ACM op 30-10-2017 08:08]

[SizzLorr]

Sorry maar, ik hoor weer allemaal technische 'what if' zaken. Los het op, mijnheer d'n lead developert.

Je hebt nu al een UBB/RML naar HTML parser (ga ik van uit). Het hoeft toch helemaal niet zo lastig te zijn om een frontend te bouwen die UBB/RML opmaak voor je maakt. De livepreview en de parser heb jezelf in handen dus het is ook geen probleem om die twee op elkaar af te stemmen.

Als er een tag tussen zit die niet ondersteund is, dan heeft de gebruiker pech, als ik nu handmatig een tag invoer die niet ondersteund is dan gebeurt er toch ook niks? Of ja, dan krijg ik iets wat ik niet bedoelde.

Ik snap even niet hoe jij erop komt dat de resulterende HTML invalid zou moeten zijn, dat zou betekenen dat ik nu ook invalid HTML kan genereren. Maar dan nog, als dat het geval is, dan is er iemand die z'n werk niet heeft gedaan.

Het is maar de vraag of jouw eigen voorbeeld onder die 'simpele' versie valt en dus of dat specifieke probleem wordt opgelost

Lees even de TS aub. Mijn specifieke probleem is dat het onnodige moeilijk is om revisies en correcties in te voeren. Een WYSIWYG editor wordt als mogelijk oplossing (en in mijn ogen beste) aangedragen. Als je een andere oplossing hebt dan hoor ik die graag.

ACM schreef op maandag 30 oktober 2017 @ 08:02:
Met een goede tokenizer (die vooraf gaat aan de complexe parser) zal er dan steeds slechts 1 text-token uitkomen als er geen brackets inzitten. Dus die inefficientie is dan in ieder geval al automatisch opgelost

Ik heb het over een onkeypress.

[Voor 16% gewijzigd door SizzLorr op 30-10-2017 15:17]

[SizzLorr]

ACM schreef op maandag 30 oktober 2017 @ 08:02:
- KNIP -

Door al dit gedoe over een simpele editor dreigt een andere feature onder te sneeuwen, namelijk:

Daarnaast zou ik het ook handig vinden als je foto's direct kan uploaden naar je galerij of vanuit je galerij foto's en thumbnails kan invoegen.

We kunnen het er waarschijnlijk wel over eens worden dat dit iig wel handig zou zijn. Zeker omdat extern gehoste plaatjes een beperkte houdbaarheid hebben en om de content van je site intakt te houden wil je dat de plaatjes ook op je site blijven.

[ACM]

SizzLorr schreef op maandag 30 oktober 2017 @ 15:14:
Sorry maar, ik hoor weer allemaal technische 'what if' zaken. Los het op, mijnheer d'n lead developert.

Sja, zodra je om iets vraagt dat technisch heel lastig is, gaan wij daarop reageren met de uitleg waarom dat zo is. Laten we voor het gemak aannemen dat met onze rml een wysiwyg-editor erg veel werk is om te maken...
Dan zouden we misschien zelfs wel moeten overstappen op een compleet andere (en iig veel simpelere) opmaaktaal, maar ook dat heeft natuurlijk weer de nodige voeten in aarde.

Je hebt nu al een UBB/RML naar HTML parser (ga ik van uit). Het hoeft toch helemaal niet zo lastig te zijn om een frontend te bouwen die UBB/RML opmaak voor je maakt. De livepreview en de parser heb jezelf in handen dus het is ook geen probleem om die twee op elkaar af te stemmen.

Maar een live-preview of met 1-druk-op-de-knop preview is inderdaad iets heel anders en ook veel eenvoudiger.

Dan kunnen we domweg via een ajax-call de bijbehorende weergave vanuit php-code ophalen en presenteren. Een echte live-preview zal wel niet lukken, domweg omdat dat sowieso tamelijk irritant is (je wil niet dat je browser traag wordt terwijl je tekst zit te typen) en complex kan worden zodra iemand nog halverwege zijn tag is met typen.
Maar een preview die verschijnt/verandert als je even pauze neemt tijdens het typen is vast ook wel mogelijk.

Als er een tag tussen zit die niet ondersteund is, dan heeft de gebruiker pech, als ik nu handmatig een tag invoer die niet ondersteund is dan gebeurt er toch ook niks? Of ja, dan krijg ik iets wat ik niet bedoelde.

Maar een tag intypen die we wel ondersteunen, maar niet in een editor is iets heel anders dan een tag die we helemaal niet ondersteunen. Zo'n wyswiwyg-editor is tenslotte bedoeld om de gebruiker te helpen, niet om 'm te verwarren of juist in de weg te zitten.

Ik snap even niet hoe jij erop komt dat de resulterende HTML invalid zou moeten zijn, dat zou betekenen dat ik nu ook invalid HTML kan genereren. Maar dan nog, als dat het geval is, dan is er iemand die z'n werk niet heeft gedaan.

Een replace-based variant zal invalid HTML op kunnen leveren. We hebben nu geen replace-based variant.

Lees even de TS aub. Mijn specifieke probleem is dat het onnodige moeilijk is om revisies en correcties in te voeren. Een WYSIWYG editor wordt als mogelijk oplossing (en in mijn ogen beste) aangedragen. Als je een andere oplossing hebt dan hoor ik die graag.

Je hebt een heel verhaal in je TS en een hele discussie eronder, met bovendien een titel die vraagt om WYSIWYG.
Wat dat betreft heb je je een beetje schuldig gemaakt aan wat wij zelf intern ook te veel doen; een oplossing aandragen voor een probleem, ipv het probleem zelf aandragen. In dit geval een 'beetje' schuldig, omdat je inderdaad dat probleem ook uitgebreid hebt beschreven.

Maar met name door je titel (en het herhalend suggereren dat een wysiwyg editor hardstikke simpel is ) is de discussie uiteindelijk verzandt in vooral iets over wysiwyg. En daar zijn wij natuurlijk hartelijk op ingegaan, zonder nog stil te staan bij een eenvoudigere oplossing

Zoals gezegd is een (min of meer live) preview veel eenvoudiger dan eentje waar de preview en editor hetzelfde zijn (zoals in een wysiwyg editor).

Ik heb het over een onkeypress.

Je moet onkeypress zo min mogelijk doen, liefst niks. Het wordt zeer onaangenaam typen als je browser steeds werk moet doen bij elke keer dat er op een knop wordt gedrukt. Dan zie je in het ergste geval je letters met veel en/of onregelmatige vertraging verschijnen... en dat is ook weer heel erg hinderlijk.
Tijdens een keypress e.o.a. asynchroon werkende timer starten, die tijdens een pauze in het typen daadwerkelijk aan het werk gaan, is waarschijnlijk wel goed mogelijk.

SizzLorr schreef op maandag 30 oktober 2017 @ 23:50:
Door al dit gedoe over een simpele editor dreigt een andere feature onder te sneeuwen, namelijk:

Het had wel geholpen als je die feature dan ook los had ingediend (ongeacht of er discussie komt)
Aanpassingen aan de preview-flow vind ik trouwens iets anders dan aanpassingen aan de editor, en een 'simpele (wysiwyg) editor' bestaat wat ons betreft dus niet. Althans, een simpele editor hebben we al

We kunnen het er waarschijnlijk wel over eens worden dat dit iig wel handig zou zijn. Zeker omdat extern gehoste plaatjes een beperkte houdbaarheid hebben en om de content van je site intakt te houden wil je dat de plaatjes ook op je site blijven.

Sterker nog, een paar jaar geleden hebben we zelfs met dat doel de afbeeldingen bij productreviews al gerefactored. Helaas betekent het wel ook nog een aardige aanpassing aan het fotoalbum om dat er ook geschikt voor te maken. Dus de wens is er, maar is helaas ondertussen overspoeld met diverse andere wensen en ergens in de min-of-meer vergetelheid geraakt.

Ik heb de bijbehorende 'productowner' iig weer aan die wens herinnert. Maar zoals gezegd is het dus geen triviale klus, dus verwacht ajb niet dat het er morgen ligt.

Ik heb 'm trouwens ook gewezen op het door jou gemelde probleem dat er een grote 'disconnect' zit tussen het invoeren van tekst en het zien van het eindresultaat. Dat met name relevant is voor de uitgebreide reviews. Dan mag hij bedenken of hij graag een wysiwyg-editor wil inzetten, dat we vooralsnog inzetten op e.o.a. 'snelle preview' of nog een heel ander idee gaan uitwerken

[Voor 4% gewijzigd door ACM op 31-10-2017 08:04]

[SizzLorr]

ACM schreef op dinsdag 31 oktober 2017 @ 07:58:
[...]

Maar een live-preview of met 1-druk-op-de-knop preview is inderdaad iets heel anders en ook veel eenvoudiger.

* KNIP *

Je hebt een heel verhaal in je TS en een hele discussie eronder, met bovendien een titel die vraagt om WYSIWYG.
Wat dat betreft heb je je een beetje schuldig gemaakt aan wat wij zelf intern ook te veel doen; een oplossing aandragen voor een probleem, ipv het probleem zelf aandragen. In dit geval een 'beetje' schuldig, omdat je inderdaad dat probleem ook uitgebreid hebt beschreven.

Een livepreview en een editor verschillen toch niet zoveel van elkaar, of zeg ik nou rare dingen? Een editor is niks anders als een livepreview waar je in kan schrijven.

Je moet onkeypress zo min mogelijk doen, liefst niks. Het wordt zeer onaangenaam typen als je browser steeds werk moet doen bij elke keer dat er op een knop wordt gedrukt. Dan zie je in het ergste geval je letters met veel en/of onregelmatige vertraging verschijnen... en dat is ook weer heel erg hinderlijk.
Tijdens een keypress e.o.a. asynchroon werkende timer starten, die tijdens een pauze in het typen daadwerkelijk aan het werk gaan, is waarschijnlijk wel goed mogelijk.

Snap je nu waarom ik zei dat je niet hele HTML bodies moet gaan parsen?

Ik heb de bijbehorende 'productowner' iig weer aan die wens herinnert.

Aha kijk, daar heb ik wat aan.

[Voor 4% gewijzigd door SizzLorr op 01-11-2017 00:23]

[ACM]

SizzLorr schreef op woensdag 1 november 2017 @ 00:20:
Een livepreview en een editor verschillen toch niet zoveel van elkaar, of zeg ik nou rare dingen? Een editor is niks anders als een livepreview waar je in kan schrijven.

Nee, daar zit echt een heel groot verschil in.

Bij een editor moet je 'editable' content hebben, dat is al een uitdaging op zich. Nou bestaan er natuurlijk 'off the shelve' wysiwyg editors voor html, waarbij sommige zelfs een ubb-plugin kennen. Maar dan ben je er nog niet. Zo'n standaard ubb-plugin past sowieso niet bij onze veel complexere, en customized, ubb, dus die moeten we dan uit zien te breiden. Veel tags hebben relatief veel functionaliteit verborgen, zoals de [topic]-tag waarbij automatisch de een topictitel wordt geplaatst. Die zou dan bij een client-side editor dan ook nog e.o.a. ajax-backend nodig hebben. En per tag die zoiets nodig heeft is er dan een losse ajax-backend nodig (daar zal uiteraard veel code gedeeld kunnen worden).

En ook als we een wysiwyg-editor zouden maken die slechts een subset van de tags ondersteund, zal die nog steeds alsnog een zekere mate van ondersteuning voor alle andere tags moeten hebben. Al is het maar om ze te herkennen als valide tag en ze dan met rust te kunnen laten.

Veel van dat soort aspecten zitten natuurlijk ook in de serverside parser... maar die hebben we al. Die ook inzetten voor een live-preview betekent via ajax de ingevoerde ubb opsturen, daarna dezelfde code uitvoeren als bij een reactie-submit en dat terugsturen als antwoord.

Hoedanook, ik begrijp zeker dat een wysiwyg editor nog wat meer voorbeelden biedt dan een live-preview. Want je bent dan verlost van een groot deel van de heen-en-weer interactie.
Maar de argumentatie dat een wysiwyg-editor eenvoudig zou zijn is gewoon onjuist

Snap je nu waarom ik zei dat je niet hele HTML bodies moet gaan parsen?

Jahoor. Maar daar ontkom je niet zomaar aan. Stel iemand begint met een code-opentag en gaat dan de code handmatig intypen... Als letterlijk die tekst telkens compleet geparsed wordt, kunnen we herkennen dat zodra er een code-sluiten tag is toegevoegd, dat dat hele stuk tekst met highlighting moet worden gepresenteerd.

Als we het 'beetje bij beetje' proberen, gaat die highlight al niet (goed) werken omdat veel dingen in programmeertalen context-gevoelig gehighlight moeten worden (denk aan teksten die 'string' zijn).
En dat gaat er dan nog van uit dat we uberhaupt nog 'weten' dat er eerder een code-opentag was geplaatst

'Helaas' zijn er gewoon best wat tags die invloed hebben op een groter geheel dan puur heet toevoegen van een html-open- en een html-sluittag.

[SizzLorr]

ACM schreef op woensdag 1 november 2017 @ 07:51:
[...]

Nee, daar zit echt een heel groot verschil in.

Bij een editor moet je 'editable' content hebben, dat is al een uitdaging op zich. Nou bestaan er natuurlijk 'off the shelve' wysiwyg editors voor html, waarbij sommige zelfs een ubb-plugin kennen. Maar dan ben je er nog niet. Zo'n standaard ubb-plugin past sowieso niet bij onze veel complexere, en customized, ubb, dus die moeten we dan uit zien te breiden. Veel tags hebben relatief veel functionaliteit verborgen, zoals de [topic]-tag waarbij automatisch de een topictitel wordt geplaatst. Die zou dan bij een client-side editor dan ook nog e.o.a. ajax-backend nodig hebben. En per tag die zoiets nodig heeft is er dan een losse ajax-backend nodig (daar zal uiteraard veel code gedeeld kunnen worden).

En ook als we een wysiwyg-editor zouden maken die slechts een subset van de tags ondersteund, zal die nog steeds alsnog een zekere mate van ondersteuning voor alle andere tags moeten hebben. Al is het maar om ze te herkennen als valide tag en ze dan met rust te kunnen laten.

Veel van dat soort aspecten zitten natuurlijk ook in de serverside parser... maar die hebben we al. Die ook inzetten voor een live-preview betekent via ajax de ingevoerde ubb opsturen, daarna dezelfde code uitvoeren als bij een reactie-submit en dat terugsturen als antwoord.

Hoedanook, ik begrijp zeker dat een wysiwyg editor nog wat meer voorbeelden biedt dan een live-preview. Want je bent dan verlost van een groot deel van de heen-en-weer interactie.
Maar de argumentatie dat een wysiwyg-editor eenvoudig zou zijn is gewoon onjuist

Sorry hoor, maar ik lees alweer: "bla bla bla, technisch moeilijk en ik wil niet". Volgens mij maak jij het in je hoofd veel moeilijk dan het hoort te zijn. De serverside parser is iets wat jezelf in de hand hebt en de clientside parser kan je makkelijk daarop afstemmen. Of je nou via live typing het voorbeeld rechts van je box of in de box laat zien is volgens mij niet veel anders van elkaar, of was je van plan om elke 20ms een nieuw voorbeeld op te vragen bij de server?

Jahoor. Maar daar ontkom je niet zomaar aan. Stel iemand begint met een code-opentag en gaat dan de code handmatig intypen... Als letterlijk die tekst telkens compleet geparsed wordt, kunnen we herkennen dat zodra er een code-sluiten tag is toegevoegd, dat dat hele stuk tekst met highlighting moet worden gepresenteerd.

Als we het 'beetje bij beetje' proberen, gaat die highlight al niet (goed) werken omdat veel dingen in programmeertalen context-gevoelig gehighlight moeten worden (denk aan teksten die 'string' zijn).
En dat gaat er dan nog van uit dat we uberhaupt nog 'weten' dat er eerder een code-opentag was geplaatst

'Helaas' zijn er gewoon best wat tags die invloed hebben op een groter geheel dan puur heet toevoegen van een html-open- en een html-sluittag.

Ga maar eens kijken naar dingen als InteliType, Notepad++ en Eclipse. Sowieso snap ik niet wat jij bedoelt met context gevoelig gehighlight. Een tag geeft aan dat bepaalde attributen aangepast moeten worden. Enige wat je hoeft te doen is een bepaalde attribuut setten als je een tag tegenkomt en daarmee ophouden als je een close tag tegenkomt. Ik snap niet waarom je er zo'n uitgebreid verhaal van moet maken. Als je kijkt naar alle UBB tags die jullie ondersteunen is het niet zo lastig. Deel is opmaak setten en ander deel is een kwestie van een template maken en dat invoegen op plaatsen waar die tag wordt gebruikt.

De dingen waar je het over hebt zijn al eeuwen geleden opgelost en daarom vind ik het raar dat je er steeds over begint. Dit is toch een kwestie van even opzoeken en kijken wat de mogelijkheden zijn.

[Voor 5% gewijzigd door SizzLorr op 01-11-2017 14:42]

[ACM]

SizzLorr schreef op woensdag 1 november 2017 @ 14:38:

Sorry hoor, maar ik lees alweer: "bla bla bla, technisch moeilijk en ik wil niet".

Als je 'bla bla bla' leest, dan denk ik dat het verder weinig zin heeft hierop te antwoorden.

Het feit dat het technisch moeilijk is, zorgt ervoor dat het bij ons niet zomaar even tussendoor gefixed zal worden.

Volgens mij maak jij het in je hoofd veel moeilijk dan het hoort te zijn. De serverside parser is iets wat jezelf in de hand hebt en de clientside parser kan je makkelijk daarop afstemmen. Of je nou via live typing het voorbeeld rechts van je box of in de box laat zien is volgens mij niet veel anders van elkaar, of was je van plan om elke 20ms een nieuw voorbeeld op te vragen bij de server?

Een wysiwyg editor met een eigen parser voor rml is gewoon een complex ding, maar vooral ook iets heel anders dan 'domweg een parser'. Dat jij dat niet van me wilt aannemen verandert daar weinig aan. Een versie - en dat is geen wysiwyg - die een live-preview steeds via de server ophaalt is technisch een stuk simpeler, hoewel zelfs dat niet triviaal is.

Een variant die via een client-side parser van de ingetypte rml een live-preview maakt betekent dat we dan twee versies moeten onderhouden. Aangezien de ene in php en de (niet bestaande) andere in javascript zijn gemaakt, is dat niet alleen maar 'afstemmen', er zal dan een taal-specifieke herimplementatie moeten komen. En dan moeten er bovendien twee onderhouden.
Ik weet niet eens of zo'n taal-specifieke herimplementatie wel echt veel makkelijker is dan domweg een bestaande wysiwyg-editor uitbreiden met een subset van onze rml (en dan ondersteuning geven om de overige valide rml te negeren).

Enige wat je hoeft te doen is een bepaalde attribuut setten als je een tag tegenkomt en daarmee ophouden als je een close tag tegenkomt.

Dat is (een vorm van) context-gevoelig werken, state bijhouden aan de hand van een zogenaamde tokenstream.
Maar het is alsnog niet zo simpel als je stelt. In de praktijk wordt namelijk best vaak een foutje gemaakt door gebruikers; parsers (van elke soort invoer, dus niet alleen rml) hebben zelfs bij wijze van spreken meer code nodig om fouten te herkennen en herstellen dan om perfecte invoer te parsen.

Mede om daar goed van te herstellen heb je eigenlijk steeds de mogelijkheid nodig om een heel eind van de tekst terug te kunnen gaan, soms zelfs helemaal naar het begin. Of anders gezegd; het is niet vaak het makkelijkst om dan sowieso maar vanaf het begin te beginnen.

Als je kijkt naar alle UBB tags die jullie ondersteunen is het niet zo lastig. Deel is opmaak setten en ander deel is een kwestie van een template maken en dat invoegen op plaatsen waar die tag wordt gebruikt.

Heb je die lijst daadwerkelijk bekeken?

De dingen waar je het over hebt zijn al eeuwen geleden opgelost en daarom vind ik het raar dat je er steeds over begint. Dit is toch een kwestie van even opzoeken en kijken wat de mogelijkheden zijn.

Ze zijn vast al opgelost in andere tools en/of voor andere talen, maar als je een eigen 'domain specific language' hebt (een wat wetenschappelijke naam voor zoiets als onze ubb/rml) dan moet je diverse van die aspecten soms alsnog zelf uitwerken.
Het is niet alsof we zomaar even (de c++-code van) notepad++ kunnen kopieren en in onze php- en/of javascript-code kunnen verwerken. En off-the-shelve editors zoals CKeditor hebben een hele simpele ubb-ondersteuning die niet al onze tags ondersteund. Dus ook daarin moeten we dingen toevoegen, juist de moeilijkste tags missen daar nog in...

En natuurlijk zal het niet een project ter grootte van de linux-kernel zijn, maar het is alsnog niet triviaal. En dat wordt het ook niet door te herhalen dat wij in jouw ogen te moeilijk denken.

SizzLorr schreef op zaterdag 28 oktober 2017 @ 00:13:
Ik zal het nogmaals en voor de laatste keer herhalen, daar ben ik het absoluut niet mee eens. Is een kwestie van een lookup table die opmaak vertaalt in UBB code, denk dat een stagaire binnen een dag iets werkend heeft. Maar goed, alles is al gezegd.

Dit is dus in onze ogen gewoon onjuist. Aangezien wij dat werk ook daadwerkelijk moeten doen, en inschatten op basis van voorgaande kennis (o.a. op basis van de inzet van ckeditor als interne html-editor in een ander project en een recente refactor van de rml-parse-code), heeft het niet zoveel zin ons er steeds er op te wijzen dat dat onzin is. Natuurlijk komt die schatting deels voort uit 'gut feeling', maar de kans dat het dan een paar uur werk zijn.

[SizzLorr]

Ik kan nou wel weer ingaan op alles maar we gaan rond in cirkels, ik ben nog seeds van mening dat het allemaal niet zo moeilijk hoeft te zijn. Nog wel een paar opmerkingen.

Heb je die lijst daadwerkelijk bekeken?

Ja, had op de vorige pagina er zelf naar gelinkt. Daarom zeg ik dat dat allemaal niet zo lastig hoeft te zijn. Ik heb ook gezegd dat ik het best voor jullie wil doen, maar dan factureer ik mijn uren wel door.

Het is niet alsof we zomaar even (de c++-code van) notepad++ kunnen kopieren en in onze php- en/of javascript-code kunnen verwerken.

Een taal is niks anders als een dialect van een computer. Sommige dingen zijn misschien beter geregeld in andere talen omdat ze er specifiek op zijn bedacht, maar dat neemt niet weg dat je alles kan implementeren in elke taal. Eclipse is geschreven Java en PHP is een C/Python afgeleide. Javascript is weer Java wat weer is afgeleid van C/C++. Die talen lijken allemaal op elkaar. Brainfuck uitgesloten!

[Femme]

Wellicht is het al een oplossing om een minimale wysiwyg-implementatie te doen waarin headings en afbeeldingen wysiwyg worden weergegeven, zodat een lange review een stuk scanbaarder wordt in de editor.

Verder lijkt het me een grote verbeteringen om betere elementen te bedenken voor de weergave van afbeeldingen. Gerommel met tabellen om afbeeldingen naast elkaar te plaatsen moeten we niet willen. Mooier zou zijn als er een imagegallery-tag bij elkaar geklikt kan worden uit afbeeldingen die je bij de review hebt geupload.

Paginering toevoegen een user reviews voegt veel complexiteit toe in zowel het formulier als de weergave. Aangezien we ook voor redactionele reviews naar een single page weergave willen gaan vind ik het niet logisch om hier tijd en moeite in te stoppen.

Wat ook wel handig zou zijn is als je de tekst van een review in de 'voorkant' kunt editen, waar de review ook wordt gepresenteerd. Als dan somehow de positie van de muiscursor vertaald kan worden naar de positie van de cursor in het tekstveld wordt het veel makkelijker om al lezend een bepaalde alinea te bewerken in een lange review.

[Hero of Time]

Voor dat laatste, zou het een idee kunnen zijn om per heading een edit optie te hebben, waarbij je alleen dat deel kan bewerken? Dus dat je van de ene H-tag naar de volgende de editor hebt, ipv de hele lap tekst.

[crisp]

Hero of Time schreef op donderdag 2 november 2017 @ 14:19:
Voor dat laatste, zou het een idee kunnen zijn om per heading een edit optie te hebben, waarbij je alleen dat deel kan bewerken? Dus dat je van de ene H-tag naar de volgende de editor hebt, ipv de hele lap tekst.

Dat gaat natuurlijk al niet meer werken op het moment dat iemand een [table] om z'n hele review knalt

De enige manier om een review in delen te kunnen bewerken is imo als je echt met fysieke 'hoofdstukken' werkt aan de achterkant (die je aan de voorkant weer simpel aan elkaar 'stitched'). Dat kan een stuk simpeler nog dan de paginering van onze redactionele reviews.

offtopic:
en of 'single-page' nou echt zaligmakend is daar zijn de meningen ook over verdeeld

[Voor 6% gewijzigd door crisp op 02-11-2017 14:53]

[Hero of Time]

crisp schreef op donderdag 2 november 2017 @ 14:51:
[...]

Dat gaat natuurlijk al niet meer werken op het moment dat iemand een [table] om z'n hele review knalt

Waarom niet? Je kan alles er omheen als invisible text opslaan bij het tonen van de editor en dan "invisible-before + editor input + invisible-after" doen voordat je de boel verstuurd. Dan heb je alleen de table-tag in de before variabele als je H1 wilt bewerken. Je kan natuurlijk ook bij zulke gevallen het gedeeltelijk bewerken weglaten. Er zijn genoeg mogelijkheden voor opmaak en mooie scheiding tussen secties zonder te moeten grijpen naar tabellen. Het is al bewezen dat het gebruik van tabellen slecht is voor responsive weergave.

De enige manier om een review in delen te kunnen bewerken is imo als je echt met fysieke 'hoofdstukken' werkt aan de achterkant (die je aan de voorkant weer simpel aan elkaar 'stitched'). Dat kan een stuk simpeler nog dan de paginering van onze redactionele reviews.

Dat is wel hoe ik een review graag zie, dat er Hx tags wordt gebruikt ipv plaatjes en andere opmaak met tabellen e.d. om de review in te delen. Door delen te kunnen bewerken ipv alles in een enkel veld beloon je gebruikers in principe om op die manier te werken.

[crisp]

@Hero of Time: wat ik bedoel is dat je bij het 'bewerken in delen' zonder dat het aparte entiteiten zijn je niet kan garanderen dat het geheel qua nesting blijft kloppen. Je haalt immers een deel van de content geheel uit zijn context.

Dat tabellen evil zijn hoef je me niet te vertellen; dat gebruikte ik puur ter illustratie (hoewel veel reviewers er blijkbaar wel aan verknocht zijn).

In ieder geval lijkt een oplossing om een review in delen te kunnen editten me eenvoudiger dan een 'minimale wysiwyg-implementatie' (waarvan ik betwijfel of dat wel bestaat ).

Als we *echt* wysiwyg willen dan moeten we de gebruikers een dichtgetimmerde CK geven zoals we nu voor de redactie aan het bouwen zijn, met widgets voor galleries, imageviewer, video etc. Alles tussen de huidige methode en full-blown wysiwyg zal toch meh blijven ben ik bang.

[Voor 19% gewijzigd door crisp op 02-11-2017 15:52]

[Hero of Time]

Voor het bewerken maakt het toch niet uit dat het uit de context wordt gehaald? De rest van de code neem je nog steeds mee en stuur je als 1 geheel naar de parser. Je splitst het geheel op de H-tag. Komt er geen volgende H-tag dan ben je klaar en heb je alleen een pre-cut deel. Stel dit voor:

code:

[h1]De titel van de review[/h1]
Korte samenvatting over het product, spel of programma.

[h2]Eerste hoofdstuk[/h2]
Introductie wat voor product het is, etc.

[h2]Tweede hoofdstuk[/h2]
Meer verdieping over en eventuele achtergrond.

etc.

Als je dan het eerste hoofdstuk wilt bewerken, komt alles voor dat hoofdstuk in een pre variabele, alles vanaf het tweede hoofdstuk komt in een post variabele. Bij submit komen pre, edit en post samen als een geheel. Nu gebruik ik h2 als enige subniveau, maar als er een h3 wordt gebruikt is dat de scheiding. Het is hoe delen bewerken bij Dokuwiki werkt. Praktisch en best prettig.

[stier]

Zou voor het forum ook wel handig zijn, omdat je met veel quotes in 1 bericht al snel het overzicht kwijt bent.

[nino_070]

En even een heel andere richting op denken: zou een soort iframe een mogelijkheid zijn die de “voorbeeld” functie in hele lange posts/reviews meescrollt met waar de tekst wordt bewerkt op dat moment (waar de cursor is), en dat dit iframe dan elke 1 minuut of elke 10 seconde wordt bijgewerkt oid. Dan gebruik je gewoon dezelfde editor en preview modus als nu en je hoeft geen wysiwyg te implementeren in de editor.

[Femme]

crisp schreef op donderdag 2 november 2017 @ 15:49:
@Hero of Time: wat ik bedoel is dat je bij het 'bewerken in delen' zonder dat het aparte entiteiten zijn je niet kan garanderen dat het geheel qua nesting blijft kloppen. Je haalt immers een deel van de content geheel uit zijn context.

Dat tabellen evil zijn hoef je me niet te vertellen; dat gebruikte ik puur ter illustratie (hoewel veel reviewers er blijkbaar wel aan verknocht zijn).

In ieder geval lijkt een oplossing om een review in delen te kunnen editten me eenvoudiger dan een 'minimale wysiwyg-implementatie' (waarvan ik betwijfel of dat wel bestaat ).

Ok, dan stel ik voor het volgende:

• Aan de opslag van de review doen we niets, de tekst zit in één databaseveld.
• In het formulier splitsen we de review op in tekstvelden per hoofdstuk (op basis van h1-tag).
• Dit wordt getoond als een lijstje uitklapbare hoofdstukken waarvan de volgorde via sleur & pleur gewijzigd kan worden. Uitgeklapt krijg je het tekstveld met de inhoud van het hoofdstuk te zien.
• Er verandert niets voor users die eenvoudige reviews zonder indeling in hoofdstukken maken.