Soepermark, is het wat? /DEVBOEK

Door ikbenmelle op maandag 12 oktober 2015 14:30 - Reacties (8)
Categorie: Devboek, Views: 4.379

TL;DR Soepermark is een markup taal met een parser in JavaScript en bijzondere mogelijkheden: o.a. syntaxhighlighting, comments, calculations, etc. Zal ik dit doorontwikkelen?

Tijdens de ontwikkeling van een recent project, ging ik van WordPress naar een eigen CMS. Mijn voorkeur voor de teksteditor ging hierbij uit naar een markup systeem in plaats van een WYSIWYG, maar bestaande oplossingen voldoen niet aan mijn eisen. Zo wil ik live parsing (zodat ik direct de output kan zien), syntax highlighting en een logische, uitbreidbare syntax. Daarmee viel Markdown af, met inconsistente markup (** dikgedrukt, * scheefgedrukt)... en andere alternatieven zijn ook niet fantastisch.

Tijd om zelf een markup-syntax met parser te ontwikkelen.

In sommige aspecten lijkt Soepermark op CommonMark (spec voor Markdown) en Textile, maar andere niet. Zo kun je het mode kiezen (soepermark, block of inline) en er zijn andere interessante features in de huidige work-in-progress versie:

1. syntax aanpasbaar (JSON),
2. inline berekeningen mogelijk (met Math.js library),
3. bb-achtige tekstblokken zijn gereserveerd voor back-end functies,
4. comments mogelijk (met geen output),
5. syntaxhighlighting,
6. HTML-invoer optioneel,
7. notices, warnings en errors worden automatisch gegenereerd,
8. attributes instelbaar met de syntax (voor id, classes, etc.),
9. valide HTML (syntax wordt automatisch gesloten, met opmerking)
10. statistiek (met aantal woorden, headers, etc.)

Met of zonder highlighting
Met of zonder syntax highlighting. Een groot verschil qua gebruiksvriendelijkheid

Hoe werkt het?

De parser is geheel VanillaJS en kan na het inladen worden geinitialiseerd met: var soepermarkObject = new Soepermark({id:'id_of_textarea'});. Daar rolt vervolgens een JSON-object uit met highlighting, outputting, input, stats en nog veel meer. Bij elk 'input' event kun je het object updaten met soepermarkObject.update() en de highlighting, output, stats, etc. injecteren: dom_of_highlighting_container.innerHTML = soepermarkObject.outputting;. De informatie van het object kun je met AJAX naar de server sturen, handig als je bijvoorbeeld het aantal woorden wil weergeven boven een artikel.

Waar staat Soepermark nu?

Probeer de work-in-progress versie: http://soepermark.mellewynia.nl

Er is nog veel te verbeteren en toe te voegen aan Soepermark. Vrijwel alles moet gerefactored worden en syntax(parsing) voor afbeeldingen en lijstjes ontbreekt nog. De huidige versie voldoet inmiddels wel voor het bedoelde gebruik en ondertussen speel ik met de gedachte om een spec te schrijven, Soepermark verder te ontwikkelen en op GitHub te zetten (onder een vrije licentie)... ik hoor graag jouw mening/idee/suggestie!

PS Mocht je je afvragen hoe het met Eve is, door drukte zijn de prioriteiten wat verschoven. Het komt eraan!

Volgende: API en React Componenten in Eve /DEVBOEK 02-'16 API en React Componenten in Eve /DEVBOEK
Volgende: De volgende stap met Eve /DEVBOEK 08-'15 De volgende stap met Eve /DEVBOEK

Reacties


Door Tweakers user Jogai, maandag 12 oktober 2015 17:00

Goed blog!

Mijn gedachten hierbij:
First of all: https://xkcd.com/927/
live parsing & syntax highlighting
Dit zou een feature van een editor zijn, niet van een syntax standaard. Het is vrij makkelijk te maken met bijv codemirror wat iemand hier heeft gedaan: http://jbt.github.com/markdown-editor
inconsistente markup (** dikgedrukt, * scheefgedrukt)
Een enkel voorbeeld is wel mager om daarop iets af te keuren. Daarnaast, zo gek lijkt het me niet. (alhoewel ik |bold|, /italic/, _underline_ & -striktrough- logischer zou vinden, maar lijkt me dan weer breaking tov anderen).

De blocks vind ik niet helder omdat het niet duidelijk is dat de / het einde is van het block dat je begonnen bent.

Door Tweakers user GemengdeDrop, maandag 12 oktober 2015 17:02

klinkt als een soort van LaTex, maar dan gericht op CMS?

Als ik dan een suggestie mag maken: leer van LaTex, en dan bedoel ik vooral dat je niet de fouten/hinderlijkheden daarvan herhaalt.

Het hele LaTex 'ecosysteem' hangt aan elkaar van losse klassen, packages en defacto-standaarden - waardoor dingen de neiging hebben om te 'breken'. Omdat de uitwerking van een commando afhangt van de exacte context waarin het gebruikt word kan het nogal makkelijk fout gaan. En ja, je kan inderdaad alles realiseren wat je wil, want als het er niet is , dan kan je het wel maken, maar dat betekend nog niet dat alles ook erg practisch is.

Hoe dan ook, ik schrijf zelf wel in LaTex, omdat je gewoon erg coole dingen ermee kan doen als je er een beetje in zit. Maar beter is dat dingen simpel blijven.

Om dat te bereiken kan je denk ik niet anders als dat je het aantal mogelijkheden van jouw systeem serieus beperkt houd. En dat je op gegeven moment duidelijke specs opstelt van hoe dingen moeten.

Als je persť dingen ingewikkeld wil maken, dan heb je een stevige inner-platform effect te pakken. Kan je net zo goed een willeukeurig bestaande scripting/programmeer/typeset taal nemen (incidentally, LaTeX, die kan dit alles al!).

Wat ik zo leuk vind aan de voorbeeldcode die je post is de liefelijke simpliciteit. Precies dat maakt dat de mogelijkheden *die* er zijn ook goed benut kunnen worden. Als je dat vast kan houden heb je iets - als je dat niet doet heb je niks.

Door Tweakers user ikbenmelle, maandag 12 oktober 2015 23:40

@Jogai, dankje en ja, Soepermark wordt nr. 16!

Goed punt van de scheiding van de syntaxstandaard en syntaxhighlighting als feature van een editor. Goede reden wellicht ook om de code voor de syntax parsing en andere functionaliteit in de toekomst verder te scheiden.

Interessante ideeŽn voor syntax van inline elementen. Het gebruik van soeperblocks is een meer geavanceerde functie, gericht op powerusers. In veel andere markup-achtige syntaxen ontbreekt hiervoor zelfs functionaliteit... Heb je een suggestie om het duidelijker/beter te kunnen maken?

@GemengdeDrop, liefelijk simpel is mooi verwoord!

Liefelijk is eigenlijk ook een van de sterke punten van de syntax, het moet simpel genoeg zijn om direct te snappen dat *bold* is voor mensen die het voor het eerst zien. Eigenlijk is Soepermark meer een versimpelde abstractie van de onderliggende HTML dan van de opmaak, etc. van de pagina zelf. Om je vraag te beantwoorden: de syntax neemt HTML5 als uitgangspunt. Dat is 'de beperking'. De opmaak kun je zelf met CSS stijlen. Uitbreidingen kun je uiteraard maken en voor de back-end verwerking zijn [blokken] gereserveerd, die kun je op een bb-code-achtige wijze parsen via de back-end. Tijdens de ontwikkeling had ik nog niet eerder gedacht aan LaTeX, maar daar ga ik zeker nog eens even naar kijken - wellicht dat er interessante ideeŽn in zitten.

[Reactie gewijzigd op maandag 12 oktober 2015 23:41]


Door Tweakers user Flippylosaurus, dinsdag 13 oktober 2015 15:42

Open-sourcen deze hap (ook de parser) en doorontwikkelen! Geweldig idee aangezien alle andere ML talen wel z'n problemen hadden...

Door Tweakers user ikbenmelle, dinsdag 13 oktober 2015 16:13

@picob, tof! Welke andere problemen heb je gezien bij markup languages?

[Reactie gewijzigd op dinsdag 13 oktober 2015 16:14]


Door picob, donderdag 15 oktober 2015 13:39

Te veel om op te noemen. ;)
Over het algemeen is het weinig/slechte documentatie, moeilijk te begrijpen/onlogische begrippen, etc...

Door Tweakers user Jogai, vrijdag 16 oktober 2015 11:00

Hier een .net parser: https://blog.mariusschulz...1/parsing-markdown-in-net
Misschien kan je er nog wat inspiratie opdoen.

Door Tweakers user ikbenmelle, vrijdag 16 oktober 2015 22:28

@picob, daar is nog wel een weg te gaan, als ik het verder zou gaan ontwikkelen! :)

@Jogai, dank, interessant!

Reageren is niet meer mogelijk