[php] Domxml, ubb, postingML.

[brammetje]

Op het moment ben ik bezig een op xml georienteerd nieuws-systeem te maken. Op zich werkt dit natuurlijk allemaal heel erg leuk. Ik bouw een pagina op met domxml, gooi daar met sablotron een XSLletje overheen, en tada, daar is de pagina Nou wil ik een soort opmaak-taal gaan gebruiken. Het idee was de gebruiker ubb te laten schrijven, dat om te zetten naar postingML, en dat dan weer door sablotron te laten transformen.

Theoretisch werkt dat natuurlijk mooi, maar ik loop tegen een aantal dingen aan:

DomXML zet alle < en > om naar < en > als je iets aan een element toevoegt. Dit heb ik weer geprobeert te omzeilen door ze voordat ik het in xslt_process() weer terug te vervangen. Probleem is dan dat als iemand iets van <bluh> in een post zet dat dat ook een tag word. En nog wel een ongeldige -> gevolg: pagina geeft een dikke fout. Hou heb ik dat weer omzeild door de inhoud tussen <!CDATA[data hier]]> te zetten, en de postinML-tags maar te omhullen door ]]><tag><!CDATA[ . En dat werkt Wel word de xml een dikke zooi zo, heeft iemand een betere oplossing?

Verder ben ik er nog niet aan toegekomen om een fatsoenlijke UBB-parser te maken te maken die een beetje checkt of tags goed genest zijn ed. Kan dit alleen met een stack-based parser of kan dit ook met een berg regexen?

help

[marcusk]

Ik zet gewoon de hele inhoud van de posts in een CDATA-sectie, dus:

code:

<POST>
...
  <TEXT>
    <![CDATA[<?= $text ?>]]>
  </TEXT>
...
</POST>

Met <xsl:output method="text"/> zorg je ervoor dat < niet door < vervangen wordt.

Op maandag 24 december 2001 22:50 schreef PlayR het volgende:
Verder ben ik er nog niet aan toegekomen om een fatsoenlijke UBB-parser te maken te maken die een beetje checkt of tags goed genest zijn ed. Kan dit alleen met een stack-based parser of kan dit ook met een berg regexen?

Volgens mij gaat dat met een regex niet lukken, tenzij je je beperkt tot een bepaalde diepte. Maar dan wordt je expressie wel erg complex.

[brammetje]

Ja, dat kan wel, maar dan kan je dus geen opmaak-codes meer gebruiken Verder zet domXML de codes om, en niet xslt (sablotron)..

Het leek mij ook niet gaan met regexen, maar ik dacht dat onze regex-king (tomato) Daar misschien wel een leuk geintje voor had

[brammetje]

Ben ik weer
De eerste vraag heb ik opgelost
Ik heb dit als volgt gedaan:
inhoud van bericht uit database halen -> plak er een xml-declaratie boven, en omhul het zootje met root-tags. -> laat een recursieve functie je root-node in een node van het hoofd-document zetten

Als er vraag is naar deze functie moet je het even laten weten, maar eigenlijk is het een heel simpel functietje.

2e vraag blijft staan, iemand?

[mbravenboer]

Goh, zie ik hier op eens PostingML langs komen .

Algemeen over het probleem: PostingML biedt een duidelijk model aan voor het verwerken van gebruikers-input met opmaak. Er is totaal geen enkele onduidelijkheid over verkeerd geneste tags, onbekende tags, rare codes etc: het mag gewoon niet.

Als je daar dus een UBB front-end voor gaat schrijven, heb je maar verdacht weinig aan PostingML: je zult toch alle mogelijke problemen zelf moeten oplossen in je UBB-parser. PostingML is dan in feite alleen nuttig voor het stylen van de reactie content naar een willekeurige vorm met XSLT.

Over de parser: ik denk dat je toch wel met een serieuze (stack-based) parser aan de slag moet. Waarom kijk je niet ff naar een compacte XML parser (met beperkte ondersteuning voor de standaard, volledige implementaties zijn te groot) en pas je deze aan?

[Johannes]

Ja, ik vroeg me ook al af waarom je nou ook nog eens een UBB-laag er om heen wilt gooien. Dat kost alleen maar performance. Een voordeel is wel de betere controleerbaarheid, maar met een goede stackbased parser zou je makkelijk incorrecte PostingML eruit kunne halen. Ik gebruik het zelf ook, maar nog zonder enige errorchecking, aangezien ik nog niet echt de tijd heb gehad die te schrijven.

[brammetje]

[reactie op mbravenboer: Ja, leuk heh :)]

Het probleem is: Als je gewoon alleen postingML gebruikt moet je toch op de een of andere manier het gaan valideren. Doe je dat niet, dan krijgt de user dikke errors op zijn/haar bord. En dat wil je niet

Of je nou ubb valideert met een eigen parser of postingML maakt dan toch weinig uit? Het voordeel van ubb is dat het bekend is bij de gebruikers, en dat het dus makkelijker voor ze is

[mbravenboer]

PlayR: Het probleem is: Als je gewoon alleen postingML gebruikt moet je toch op de een of andere manier het gaan valideren. Doe je dat niet, dan krijgt de user dikke errors op zijn/haar bord. En dat wil je niet

Klopt, maar als je een goede XML parser gebruikt kan je de meldingen opvangen en vriendelijker maken. Validering zal de parser dan doen, een leuke melding geven doe jij .

Of je nou ubb valideert met een eigen parser of postingML maakt dan toch weinig uit?

Nou ja, dat maakt vrij veel uit... Als je PostingML valideert hoef je geen code te schrijven: de XML parser valideert voor je.

Als je UBB gaat valideren moet je eerst zelf beslissen wat mogelijk is, je moet beslissen welke incorrecte UBB je gaat herstellen en waar je een melding voor geeft en er is geen formele beschrijvingstaal voor de structuur van UBB codes...

Het voordeel van ubb is dat het bekend is bij de gebruikers, en dat het dus makkelijker voor ze is

Ach tja... leuk om eens wat nieuws te leren .

[brammetje]

Op woensdag 26 december 2001 14:47 schreef mbravenboer het volgende:
Klopt, maar als je een goede XML parser gebruikt kan je de meldingen opvangen en vriendelijker maken. Validering zal de parser dan doen, een leuke melding geven doe jij .

Uhm ja.. Maar wat nou als ik een gebruiker <blaat> in wil laten typen? Op zich geen gekke uitspraak. Maar je parser zegt dan: UHH, fout, dit is geen xml als je eerst ubb laat invoeren dan gooi je htmlspecialchars() [voor de niet php'ers: verandert < in < ed.] over je berichtje, en dan parse je de UBB.

Nou ja, dat maakt vrij veel uit... Als je PostingML valideert hoef je geen code te schrijven: de XML parser valideert voor je.

Tja, op zich kan ik DOMxml van php wel laten valideren, maar dan zit ik nog met het eerste probleem, en ik weet ook niet of tie wel xml-schema's aankan, al heb je dat niet echt nodig (?)

Als je UBB gaat valideren moet je eerst zelf beslissen wat mogelijk is, je moet beslissen welke incorrecte UBB je gaat herstellen en waar je een melding voor geeft en er is geen formele beschrijvingstaal voor de structuur van UBB codes...

Op zich geen probleem: de output moet geldige xml zijn

[mbravenboer]

PlayR: Uhm ja.. Maar wat nou als ik een gebruiker <blaat> in wil laten typen? Op zich geen gekke uitspraak. Maar je parser zegt dan: UHH, fout, dit is geen xml als je eerst ubb laat invoeren dan gooi je htmlspecialchars() [voor de niet php'ers: verandert < in < ed.] over je berichtje, en dan parse je de UBB.

Dat is het verplaatsen van het probleem: in XML mag je geen < en > gebruiken in tekst. Bij UBB moet je een keuze maken: of je laat [ ... ] ook niet toe of je gaat proberen om gebruik van [ ... ] zelf op te gaan lossen in je parser. Het voordeel van een eigen syntax en een eigen (UBB) parser is dus dat je het kunt oplossen als je dat wilt ... Maar het gebruik van UBB lost dus niet per definitie een probleem op.

Tja, op zich kan ik DOMxml van php wel laten valideren, maar dan zit ik nog met het eerste probleem, en ik weet ook niet of tie wel xml-schema's aankan, al heb je dat niet echt nodig (?)

Er kan ook wel een DTD van gemaakt worden, die snaptie vast wel..

[brammetje]

Op woensdag 26 december 2001 15:00 schreef mbravenboer het volgende:
Dat is het verplaatsen van het probleem: in XML mag je geen < en > gebruiken in tekst. Bij UBB moet je een keuze maken: of je laat [ ... ] ook niet toe of je gaat proberen om gebruik van [ ... ] zelf op te gaan lossen in je parser. Het voordeel van een eigen syntax en een eigen (UBB) parser is dus dat je het kunt oplossen als je dat wilt ... Maar het gebruik van UBB lost dus niet per definitie een probleem op.

Tja, je kan je eigen parser vertellen dattie onbekende tags of slecht geneste tags lekker mag negeren. In het eind-resultaat (XML) heb je er dan geen last meer van omdat die zich sowieso niks van [...] aantrekt.

Hmmz.. ziet er naar uit dat ik een stackbased-parser moet gaan schrijven: ACM, hellup!

[Rense Klinkenberg]

Op maandag 24 december 2001 23:26 schreef PlayR het volgende:Het leek mij ook niet gaan met regexen, maar ik dacht dat onze regex-king (tomato) Daar misschien wel een leuk geintje voor had

ok, m'n nick is dan wel anders, maar ik heb de oplossing toch een beetje gevonden.

Eigenlijk wil je alleen ge-escapede tags omzetten die ook valid xml zouden opleveren. Ze zouden dus ook gesloten moeten worden.

Daarvoor zijn met regexen ook best oplossingen voor te verzinnen. In de php manual hebben ze nl. ook een stukje staan over back-references. Da's eigenlijk exact wat je zoekt. Wat ik dus doe met de code is het volgende:

PHP:

<?
while (preg_match('!&amp;amp;lt;(.*?)&amp;amp;gt;(.*?)&amp;amp;lt;/(\\1)&amp;amp;gt;!', $DOMdump)) {
   $DOMdump = preg_replace('!&amp;amp;lt;(.*?)&amp;amp;gt;(.*?)&amp;amp;lt;/(\\1)&amp;amp;gt;!', '<\\1>\\2</\\1>', $DOMdump);
}
?>

Dit stuk code laat je werken met het geserialized DOM object. Achteraf kan je hier perfect je xsl overheen halen.

Qua perfomance zou mijn oplossing zeker nog beter kunnen, omdat zowel de preg_match() als de preg_replace() naar hetzelfde patroon gaan zoeken.

edit:
Effe een stuk betere code in elkaar gezet:

PHP:

<?
$prev = Null;
while ($DOMdump != $prev) {
    $prev = $DOMdump;
    $DOMdump = preg_replace('!&amp;lt;(.*?)&amp;gt;(.*?)&amp;lt;/(\\1)&amp;gt;!', '<\\1>\\2</\\1>', $DOMdump);
}
?>

En deze code is bij mijn metingen ruim 2x zo snel als de eerste