[Php] Stack based template engines

[Verwijderd]

Dag allemaal, na wat hulp en tips van Drm en wat andere kennisen ben ik eens wat gaan rondneuzen in de wereld van stackbased template engines, ik zelf heb laatst een template engine geschreven en moet zeggen dat die aardig rap templates encoded maar toch bleef ik met een probleem zitten rondom het gebruiken van dezelfde commandos

bv..

code:

[loop="%searchitems%"]
het total gevonden aantal items: %searchitems%
    [loop="%subitems%"]
    onder dit kopje zijn een ander aantal items gevonden: %subitems%
    [/loop]
[/loop]

op zich is dit natuurlijk te verhelpen door [loop="%text"] en [/loop="%text"] te gebruiken, maar dat wil ik niet ..

Verder heb ik ook geen idee hoe ik dit alles moet implementeren en of te herkennen, ikzelf heb vannochtend de volgende topics op aanraden van Drm door gelezen maar snapte er jammer genoeg erg weinig van, de code van ACM is zoals hij zelf al vermeld niet te doorgronden behalve als je er weken mee gaat spelen..

[topic=331671]
[topic=445817]
[topic=445584]

Ook de uitleg van mbravenboer is voor mij persoonlijk niet te begrijpen, maar dat zal komen omdat ik veel termen nog niet onder de knie heb..

Om te beginnen heb ik mijn code, die officieel niet public is maar eens online gezet
(please respect)

Mischien dat iemand mij kan helpen een oplossing te vinden..

[Verwijderd]

Mijn ubb-parser is emt regexen maar aangezien jij ook een regex gebruikt voor je loops wilde ik dit ook even laten zien, werkt bij mij ook voor moeilijke structuren als:

code:

tekst
[div border="0" style="position:relative;width: 800;" onClick="doedit();"]
  TEKSTINDEDIV
  [div]
    divindiv!
  [/div]
  [div]
    divindiv2!!!!
  [/div]
  TEKSTINDEDIV
[/div]
nog meer tekst
[div class="id" style="background:#000000;position:absolute;"]
  hihihih
  [div]
    divindiv!
  [/div]
[/div] 
blaat!

PHP:

<?function parseDivs($text, $l = 20){  $regexp = '/\\[div(( [a-z]+ ?= ?"?[^"\]]+"?)*)\](.*?)\\[\/div\]/ise';  $replacement = "'<div'.cleanParams('$1').'>$3</div>'";      while(preg_match('/\\[div(( [a-z]+ ?= ?"?[^"\]]+"?)*)\](.*?)\\[\/div\]/is',$text) &amp;&amp; --$l > 0){    $text = preg_replace($regexp, $replacement, $text);  }  return $text;}?>

[Verwijderd]

Hmmz... intressant zou je eens wat meer uitleg willen geven, want dit is ongv wat ik bedoel maar dan moeten de 'interne loopjes' ook arrays bevatten en weet verder nog niet hoe ik dat op moet gaan lossen

oftewel in php

code:

$blaat = array(1 => 'test',
          2 => "bbbb", array(test, test2, test3));

etc

[Verwijderd]

Aangezien ik dezelfde regexp ook voor de interne loopjes gebruik kunnen daar ook gewoon parameters in staan...

edit:
Laat trouwens maar even zitten, deze is ook niet goed, heb hem even met wat andere opstellingen geprobeert en dan gaat het toch mis... je zult toch iets anders moeten bedenken, denk ik ondertussen ook even mee, want ik zoek ook al een tijdje hier een oplossing voor!

[mbravenboer]

Ik ben aan het tikken, maar dat kan even duren .

[djc]

Op vrijdag 28 juni 2002 15:07 schreef mbravenboer het volgende:
Ik ben aan het tikken, maar dat kan even duren .

OMG.

[Verwijderd]

Op vrijdag 28 juni 2002 15:07 schreef mbravenboer het volgende:
Ik ben aan het tikken, maar dat kan even duren .

Be afraid, be very afraid. En zie alvast: Weet je wat frustrerend is?

[p0m]

[Heolan == p0m (ja van React)]

Op vrijdag 28 juni 2002 14:53 schreef zellufs het volgende:
Mijn ubb-parser is emt regexen maar aangezien jij ook een regex gebruikt voor je loops wilde ik dit ook even laten zien, werkt bij mij ook voor moeilijke structuren als:

code:

tekst
[div border="0" style="position:relative;width: 800;" onClick="doedit();"]
  TEKSTINDEDIV
  [div]
    divindiv!
  [/div]
  [div]
    divindiv2!!!!
  [/div]
  TEKSTINDEDIV
[/div]
nog meer tekst
[div class="id" style="background:#000000;position:absolute;"]
  hihihih
  [div]
    divindiv!
  [/div]
[/div] 
blaat!

hmm met die php code gaat het niet helemaal goed, maar omdat het allemaal dezelfde sluitings tags zijn zie je dat niet.
Om dit te illustreren heb ik de tags gepaard en van nummers voorzien, op de manier waarop de php code ze zou paren.

code:

tekst
[1! div border="0" style="position:relative;width: 800;" onClick="doedit();"]
  TEKSTINDEDIV
  [4! div]
    divindiv!
  [1! /div]
  [2! div]
    divindiv2!!!!
  [2! /div]
  TEKSTINDEDIV
[4! /div]
nog meer tekst
[3! div class="id" style="background:#000000;position:absolute;"]
  hihihih
  [5! div]
    divindiv!
  [3! /div]
[5! /div] 
blaat!

[Verwijderd]

ja dat ben ik net zelf ook achter gekomen idd... achja, verzinnen we gewoon wat anders

[Verwijderd]

Op vrijdag 28 juni 2002 15:15 schreef Heolan het volgende:
[Heolan == p0m (ja van React)]

edit: Laat maar

[mbravenboer]

Je moet twee problemen onderscheiden:

1. Parsen van je template
2. Evalueren van je template

Beide zijn hele andere problemen. Ik denk dat je om te beginnen deze problemen dus ook beter gescheiden kunt oplossen: eerst parsen, daarna evalueren. Als je tijdens het parsen tegelijk evalueert krijg je (als je het goed doet) betere performance, maar je code wordt er niet duidelijk op. Ik zal beide problemen even apart bespreken.

Parsing

Allereerst het parsing probleem. Parsen is een probleem waarbij je een String in een bepaalde taal omzet naar een boom structuur. Deze structuur geeft de interpretatie van de String tegen een grammatica van de taal. Een gramamtica voor een taal beschrijft namelijk welke strings er toegestaan zijn. Dit gebeurt met productie-regels die meestal een naam hebben. Deze naam geeft de betekenis van de constructie aan.

Een voorbeeld:

code:

IntConst: IntLiteral -> NumExp
Plus: NumExp "+" NumExp -> NumExp
Min:  NumExp "-" NumExp -> NumExp
Mul:  NumExp "*" NumExp -> NumExp
Div:  NumExp "/" NumExp -> NumExp

Je ziet hier 5 productie-regels voor numerieke expressies. De productie-regel "Plus" is opgebouwd uit een numerieke expressies, een "+" token, gevolgd door weer een numerieke expressies. De naam van deze productie is Plus. Na het parsen (hoe je aan deze parser komt, komt later ter sprake ) wordt het resultaat van het parsen meestal meteen omgezet in een Abstract Syntax Tree. Dit kan je je bijvoorbeeld zo voorstellen voor de expressie 5 + 6 - 2 (ik negeer prioriteiten details).

code:

<Plus>
   <IntConst>5</IntConst>
   <Min>
    <IntConst>6</IntConst>
    <IntConst>2</IntConst>
   </Min>
</Plus>

De string "5 + 6 - 2" is nu geparsed naar een boom-structuur die weergeeft via welke producties deze string opgebouwd is. Dit is een beetje in vogelvlucht wat een parser eigenlijk doet.

Nu de oplossing van het parsing probleem. Daar zijn verschillende oplossingen voor, waarvan sommige eigenlijk geen echte oplossingen zijn.

1) Schrijf zelf aan ad-hoc parser, zonder daarbij eerst netjes een grammatica te ontwerpen.

2) Ontwerp een goede grammatica en probeer dit gestructureerd om te zetten naar een parser.

3) Ontwerp een goede grammatica en genereer een goede parser met een parser-generator.

Dan is er nog een categorie oplossing, wat eigenlijk geen oplossingen zijn. Deze oplossingen beperken de invoer namelijk tot de abstracte syntax die normaal gesproken uit de parser komt. Ik heb de abstracte syntax tree van mijn numerieke expressie voorbeeld namelijk niet voor niets in XML geschreven. XML kan je eigenlijk zijn als een standaard syntax voor abstracte syntax trees. De abstracte syntax tree die ik gaf kan je namelijk ook gewoon gebruiken ipv de concrete syntax "5 + 6 - 2".

Wat los je hiermee op? Best veel: je hoeft helemaal geen parser meer te maken. Dat is dus oplossing 4:

4) Gebruik XML als syntax voor je template en gebruik een standaard XML parser.

Tot slot is er nog een 'tob-oplossing' en helaas zie je die veel terug:

5) Bedenk je eigen alternatief voor XML en schrijf een parser die dit alternatief kan parsen.

Huh? Maar voor abstract syntax trees had je toch juist geen parser meer nodig? Dat klopt gedeeltelijk: als je een abstracte syntax tree omzet naar gewone text, is dit in feite ook een taal geworden. Deze taal moet ook geparsed worden, maar deze parser is generiek voor alle XML documenten. 'Normale' parsers zijn specifiek voor een bepaalde concrete syntax (zoals bijvoorbeeld de numerieke expressies).

Nog even over de oplossingen 1 t/m 3: Oplossing 1 is een echte pruts oplossing. Bij deze oplossing loop je typisch tegen allemaal bugs, problemen en vergissingen aan zoals je die bijvoorbeeld ziet bij alle UBB problemen hier op GoT, maar nu ook bij jouw probleem met de sluit-tag van een loop. Oplossing 2 is al een stuk beter: je denkt goed na over de structuur van je taal en probeert dit om te zetten naar een parser. Hier is weinig mis mee, behalve dat het pokkewerk is en je waarschijnlijk geen beter resultaat zult neerzetten dan een parser-generator. Oplossing 3 is namelijk echt de beste optie van deze 3: maak een grammatica en genereer daar gewoon de parser uit met een parser-generator.

Tot zover een verhaal over parsing, waar je eigenlijk niets aan hebt om je probleem op te lossen, maar wat je misschien wel naar een betere oplossing kan sturen en daarnaast misschien ook voor een grappig nieuw inzicht in XML kan zorgen.

Interpretatie

Dan het probleem van interpretatie. Als je eenmaal een abstracte syntax tree hebt, is interpretatie eigenlijk niet zo lastig meer. Je werkt dan typisch met een soort environment zoals ik al noemde in mijn post in 1 van die topics.

Compilatie

Eigenlijk wil ik namelijk nog even wat zeggen over een veel interessantere oplossing (imho ). Je zou je templates namelijk ook kunnen omzetten naar echte PHP. Je bent dan in feite bezig met een compilatie (transformatie) van jouw template taal naar PHP.

Dit heeft een aantal grote voordelen:

1) Betere performance: interpretatie van een template in een geinterpreteerde omgeving (PHP) is gewoon erg traag.

2) Hele eenvoudige code: je hoeft je niet druk te maken om allerlei problemen als variabelen en loops omdat je gewoon de mechanismen van PHP kunt gebruiken. Hierdoor kan je je code ook goed optimaliseren en controleren.

3) Uitgebreide mogelijkheden: omdat je gebruik maakt van een doel-taal kan je heel makkelijk geavanceerdere features in je template taal opnemen. Deze features worden namelijk daadwerkelijk gerealiseerd in je doel-taal en jij hoeft je daar dus niet druk over te maken. Loops zijn hiervan een eenvoudig voorbeeld.

Nou ja, tot zover dit verhaaltje . Ik hoop dat ik je kan aanzetten tot in ieder geval een scheiding van je probleem in componenten en je wellicht zelfs richting de compilatie oplossing kan sturen .

-- edit: het oog wil ook wat .

[mbravenboer]

Zef: Be afraid, be very afraid. En zie alvast: Weet je wat frustrerend is?

Haha . Dit keer heb ik geprobeerd om het wat toegankelijker te houden . Of dat gelukt is mogen jullie zelf beoordelen .

[Verwijderd]

Ik snappet iig Zal het zometeen nóg wel een keer lezen voordat ik weer opnieuw aan de slag ga...

[Orphix]

Er is trouwens al een template engine die templates naar PHP compileert:
Smarty

Ik heb er zelf nooit echt mee gewerkt. Toch lijkt het me niet slecht om zoiets zelf te maken (evt naar een andere taal?) aangezien het vrij veel raakvlakken heeft met andere onderwerpen.

[Nielsz]

Op vrijdag 28 juni 2002 15:10 schreef Zef het volgende:

[..]

Be afraid, be very afraid. En zie alvast: Weet je wat frustrerend is?

Zeg, het was niet de bedoeling dat iedereen dat zou kunnen zien, dat was maar voor 10 mensen bedoelt

_{onder de gordel}

[Nielsz]

Goed verhaal Martin, zelfs ik begrijp het
1 kanttekening, het opslaan van die pure phpcode in de template is de methode van Smarty, die Orphix al riep.
In die engine schrijf je in de taal die zij bedacht hebben, waarna hij 'm converteert naar php en cached. Ook een hele mooie methode

[mbravenboer]

Orphix: Er is trouwens al een template engine die templates naar PHP compileert Smarty

De naam zegt het al: deze oplossing is gewoon verrot slim .

Ik wist inderdaad niet dat dit al gedaan werd door een template engine (ik ben niet zo thuis in PHP zoals jullie weten ). De oplossing ligt vanwege zijn grote voordelen natuurlijk erg voor de hand, dus zo verbazingwekkend is het niet dat dit al is gedaan.

Omdat de meeste template engines hier sowieso toch voor educatieve doeleinden gemaakt worden (alles bestaat toch al ), lijkt het me geen belemmering vormen om deze aanpak toch eens te proberen, in combinatie met 1 van de parsing aanpakken die ik voorstelde.

[mbravenboer]

Is er trouwens al een zieke geest geweest die een parser-generator die PHP uitpoept heeft geschreven?

Hebben jullie gezien dat Smarty qua performance alle andere template engines wegblaast? Dat is niet zo gek als je de aanpak bekijkt en de voordelen die ik noemde ernaast legt.

[Verwijderd]

Op vrijdag 28 juni 2002 17:28 schreef Nielsz het volgende:
[..]

Zeg, het was niet de bedoeling dat iedereen dat zou kunnen zien, dat was maar voor 10 mensen bedoelt

_{onder de gordel}

Het spijt me zo Nielszje

edit: Toch even ter verduidelijking. De reden dat ik dat topic aanhaalde was om het soms (te) hoge uitleg niveau van de heer Bravenboer te benadrukken en geenzins de heer Nielsz te kleineren.

[Verwijderd]

Op vrijdag 28 juni 2002 17:55 schreef mbravenboer het volgende:
Hebben jullie gezien dat Smarty qua performance alle andere template engines wegblaast? Dat is niet zo gek als je de aanpak bekijkt en de voordelen die ik noemde ernaast legt.

Mja, voor zover ze niet hetzelfde werken. Mijn template parser compileert ook naar PHP code, is wel minder geavanceerd maar wie heeft al die troep nodig.

[Verwijderd]

Bedankt voor de grove en wel-duidelijke uitleg, ik ga her zeker nog een keer of 10 lezen voordat ik het ga begrijpen, ik begrijp ook dat het converteren op een of andere manier van de template naar php een veel sneller idee is, en natuurlijk kan je altijd wel een parser engine gaan gebruiken die iemand anders heeft geschreven, maar dat is niet erg orgineel en daar leer je natuurlijk helemaal niets van

Zover als ik al ben gekomen met me mini parser, zover wil ik strax ook komen met een goed werkend parsend ietsje ...

al heb ik nog steeds geen idee hoe ik dit alles voor elkaar moet krijgen

--edit
Op dit moment heb ik je text 2 keer gelezen en vat bepaalde dingen niet, dat quote ik zometheen, en hoop dat je voor mij daar wat meer uitleg over kan geven. Ik leer snel, dat is een feit maar van het gene wat ik nu lees begin ik toch een beetje te duizelen

[mbravenboer]

xtentic: en natuurlijk kan je altijd wel een parser engine gaan gebruiken die iemand anders heeft geschreven, maar dat is niet erg orgineel en daar leer je natuurlijk helemaal niets van

Uiteraard is het inderdaad niet verkeerd om zelf een parser te schrijven als je dat graag wilt leren.

Ik denk dat je er dan echter wel beter voor kunt kiezen om wat literatuur over parsing algorithmen te raadplegen. Het is echt te hoog gegrepen om helemaal zelf te gaan bedenken hoe je een parser moet bouwen. Je kunt dan beter eens wat boeken of artikelen raadplegen over het bouwen van een parser, waarna je dit probeert toe te passen in je template-engine. Dit is veel dankbaarder werk omdat je dan echt een leuke oplossing kunt implementeren en tegelijk nog veel kan opsteken over grammatica's, de verschillende vormen hiervan en de verschillende parsing algoritmen

hoop dat je voor mij daar wat meer uitleg over kan geven.

Tuurlijk .

[Verwijderd]

Parsing

Allereerst het parsing probleem. Parsen is een probleem waarbij je een String in een bepaalde taal omzet naar een boom structuur. Deze structuur geeft de interpretatie van de String tegen een grammatica van de taal. Een gramamtica voor een taal beschrijft namelijk welke strings er toegestaan zijn. Dit gebeurt met productie-regels die meestal een naam hebben. Deze naam geeft de betekenis van de constructie aan.

Wat ik hier uit begrijp en hoop dat ik het goed is is dat een parser alleen zoals je al zegt een boom structuur maakt van wat moet er veranderd worden en wat mag er veranderd worden door de toegestane 'gramatica' die de template parser toestaat. De productie regels zijn gewoon (denk ik) de items (gramatica) die toegestaan zijn.

Een voorbeeld:

code:

IntConst: IntLiteral -> NumExp
Plus: NumExp "+" NumExp -> NumExp
Min:  NumExp "-" NumExp -> NumExp
Mul:  NumExp "*" NumExp -> NumExp
Div:  NumExp "/" NumExp -> NumExp

Je ziet hier 5 productie-regels voor numerieke expressies. De productie-regel "Plus" is opgebouwd uit een numerieke expressies, een "+" token, gevolgd door weer een numerieke expressies. De naam van deze productie is Plus. Na het parsen (hoe je aan deze parser komt, komt later ter sprake ) wordt het resultaat van het parsen meestal meteen omgezet in een Abstract Syntax Tree. Dit kan je je bijvoorbeeld zo voorstellen voor de expressie 5 + 6 - 2 (ik negeer prioriteiten details).

code:

<Plus>
   <IntConst>5</IntConst>
   <Min>
    <IntConst>6</IntConst>
    <IntConst>2</IntConst>
   </Min>
</Plus>

De string "5 + 6 - 2" is nu geparsed naar een boom-structuur die weergeeft via welke producties deze string opgebouwd is. Dit is een beetje in vogelvlucht wat een parser eigenlijk doet.

Okey de gramatica van deze voorbeeld is dus <Plus> om op te tellen, <Min> om af te trekken en <IntConst> om de gegeven variabel (teken of cijfer) aan te geven, maar als ik naar je voorbeeld kijk zie ik eerst plus, en dan het gedeelte min, waaruit ik logischer wijs begrijp dat je 5 + - 6 - 2 lees, omdat min al voor de 6 staat...

Nu de oplossing van het parsing probleem. Daar zijn verschillende oplossingen voor, waarvan sommige eigenlijk geen echte oplossingen zijn.

1) Schrijf zelf aan ad-hoc parser, zonder daarbij eerst netjes een grammatica te ontwerpen.

ad-hoc?... daar heb ik echter nog nooit van gehoord, maar wat ik wel begrijp is gewoon dat je non syntax je template gaat parsen dus zonder extene informatie om het zo even te noemen.

2) Ontwerp een goede grammatica en probeer dit gestructureerd om te zetten naar een parser.

Begrijp ik goed dat dit eingelijk wijst naar het gene dat ik al heb gemaakt?, want deze heeft een 'standaard' gramatica en parst deze gewoon weer naar html output zoals het ook in de 'template' vermeld staat maar dan met de veranderde delen.

3) Ontwerp een goede grammatica en genereer een goede parser met een parser-generator.

Gramatica in de zin van [loop], [ifset] [once] etc.? en dan de parser die dit om het zo even te noemen natuurlijk weer converteerd.

Dan is er nog een categorie oplossing, wat eigenlijk geen oplossingen zijn. Deze oplossingen beperken de invoer namelijk tot de abstracte syntax die normaal gesproken uit de parser komt. Ik heb de abstracte syntax tree van mijn numerieke expressie voorbeeld namelijk niet voor niets in XML geschreven. XML kan je eigenlijk zijn als een standaard syntax voor abstracte syntax trees. De abstracte syntax tree die ik gaf kan je namelijk ook gewoon gebruiken ipv de concrete syntax "5 + 6 - 2".

Het voorbeeld zoals je vermelde leek idd erg veel op XML, maar xml wordt ook geparsed voordat het de gebruiker bereikt dus verdubbel je dan de parser van 1 parser naar 2x parsen?...

Wat los je hiermee op? Best veel: je hoeft helemaal geen parser meer te maken. Dat is dus oplossing 4:

4) Gebruik XML als syntax voor je template en gebruik een standaard XML parser.

Tuurlijk en zoals ik al vermelde is XML ook al geparsed en dus minder leuk als uitdaging , het is voor mij persoonlijk een leerweg, ik speel al ruim 6 jaar met websites en dat begon met het parsen van een template in QuickBASIC naar een gewone HTML pagina maar zoals de tijd doorgaat moest ik ook door en wil nu de weg in staan van PHP.

Tot slot is er nog een 'tob-oplossing' en helaas zie je die veel terug:

5) Bedenk je eigen alternatief voor XML en schrijf een parser die dit alternatief kan parsen.

Huh? Maar voor abstract syntax trees had je toch juist geen parser meer nodig? Dat klopt gedeeltelijk: als je een abstracte syntax tree omzet naar gewone text, is dit in feite ook een taal geworden. Deze taal moet ook geparsed worden, maar deze parser is generiek voor alle XML documenten. 'Normale' parsers zijn specifiek voor een bepaalde concrete syntax (zoals bijvoorbeeld de numerieke expressies).

Dit begrijp ik niet, het is toch leuk dat meerdere mensen gaan spelen met een taal en zo proberen hun eigen dingen te maken/crearen... XML is voor zover ik het doorheb een standaard parse taal die de templates voorziet van de benodigde items, zovaak als het maar gevraagd wordt. Mja aan de andere kant: ik ken XML nog maar 0.01% ofzo

Nog even over de oplossingen 1 t/m 3: Oplossing 1 is een echte pruts oplossing. Bij deze oplossing loop je typisch tegen allemaal bugs, problemen en vergissingen aan zoals je die bijvoorbeeld ziet bij alle UBB problemen hier op GoT, maar nu ook bij jouw probleem met de sluit-tag van een loop. Oplossing 2 is al een stuk beter: je denkt goed na over de structuur van je taal en probeert dit om te zetten naar een parser. Hier is weinig mis mee, behalve dat het pokkewerk is en je waarschijnlijk geen beter resultaat zult neerzetten dan een parser-generator. Oplossing 3 is namelijk echt de beste optie van deze 3: maak een grammatica en genereer daar gewoon de parser uit met een parser-generator.

Voor zover ik het nu doe is het denk ik met oplossing 1, ik genereer gewoon de zelfde code als UBB codes maar dat werkt nog niet zoals ik het wil hebben, oplossing 2 is echter voor mij wel te doen maar vergt veel meer ervaring en kennis dan dat ik nu heb en voor oplossing 3 zie ik het somber in, ik vond het al moeilijk genoeg om me parser te schrijven op basis van een soortement ubb tag systeem: dat wel gemakkelijk is maar aan de andere kant toch moeilijk.

Tot zover een verhaal over parsing, waar je eigenlijk niets aan hebt om je probleem op te lossen, maar wat je misschien wel naar een betere oplossing kan sturen en daarnaast misschien ook voor een grappig nieuw inzicht in XML kan zorgen.

Ik denk dat het inderdaad wel handig is om eens te kijken naar wat XML allemaal bied, het heeft voor zover ik kan zien een eenvoudig en overzichtelijk iets en kan overal en nergens voor gebruikt worden: lees I-Connect en dergelijke ander internet mogelijkheden.

Interpretatie

Dan het probleem van interpretatie. Als je eenmaal een abstracte syntax tree hebt, is interpretatie eigenlijk niet zo lastig meer. Je werkt dan typisch met een soort environment zoals ik al noemde in mijn post in 1 van die topics.

Je bedoeld als je de template geparsed hebt naar een soortement grote array (tree). Dat is zoals ik al vermelde in mijn geval denk ik wel een zeer grote opgave behalve als we het over XML gaan hebben.

Compilatie

Eigenlijk wil ik namelijk nog even wat zeggen over een veel interessantere oplossing (imho ). Je zou je templates namelijk ook kunnen omzetten naar echte PHP. Je bent dan in feite bezig met een compilatie (transformatie) van jouw template taal naar PHP.

Dit heeft een aantal grote voordelen:

Dit begrijp ik nog niet evenals het idee van ZEND dat je je data kan versleutelen en dan nogmaals kan compileren door PHP, het is echter wel goed bedacht en zal ongetwijfeld grote snelheid winst maken dan het steeds maar doorversturen van data van het ene component naar het andere.

1) Betere performance: interpretatie van een template in een geinterpreteerde omgeving (PHP) is gewoon erg traag.

Dat parsers het systeem trager maken is mij idd al bekend, maar dat het zoveel zou uitmaken niet

2) Hele eenvoudige code: je hoeft je niet druk te maken om allerlei problemen als variabelen en loops omdat je gewoon de mechanismen van PHP kunt gebruiken. Hierdoor kan je je code ook goed optimaliseren en controleren.

idd, maar hoe zou dat dan te controlleren zijn? mja dit zal ongetwijfeld met mijn onwetendheid te maken zoals ik dat gene van ZEND ook al niet begrijp (nog niet).

3) Uitgebreide mogelijkheden: omdat je gebruik maakt van een doel-taal kan je heel makkelijk geavanceerdere features in je template taal opnemen. Deze features worden namelijk daadwerkelijk gerealiseerd in je doel-taal en jij hoeft je daar dus niet druk over te maken. Loops zijn hiervan een eenvoudig voorbeeld.

idd als je zoiets zou realiseren in een soortement geparsde php dan zouden loops een peace of cake worden imho.

Nou ja, tot zover dit verhaaltje . Ik hoop dat ik je kan aanzetten tot in ieder geval een scheiding van je probleem in componenten en je wellicht zelfs richting de compilatie oplossing kan sturen .

Mag ik je vriendelijk bedanken, ik heb genoten en geleerd van je uitleg en hoop dat ik er straks nog meer van kan gaan benutten in de toekomst van het werken aan me mega grote babes site want daar is dit alles om begonnen. Verder zal ik gaan spacen op XML al wil ik toch wel proberen mijn parser eerst NON XML te houden omdat ik op die manier PHP nog beter onder de knie kan krijgen alsdat ik het nu heb. Ook vind ik het jammer dat bepaalde uitleggen voor mij als vele vraagtekens bij mij overkomen, dit zal echter door mijn eigenschuld (gekapt met school ivm mooie werk aanbieding toen die tijd) gekomen zijn.

Nogmaals vriendelijk bedankt.

Op vrijdag 28 juni 2002 19:19 schreef mbravenboer het volgende:
Uiteraard is het inderdaad niet verkeerd om zelf een parser te schrijven als je dat graag wilt leren.

Ik denk dat je er dan echter wel beter voor kunt kiezen om wat literatuur over parsing algorithmen te raadplegen. Het is echt te hoog gegrepen om helemaal zelf te gaan bedenken hoe je een parser moet bouwen. Je kunt dan beter eens wat boeken of artikelen raadplegen over het bouwen van een parser, waarna je dit probeert toe te passen in je template-engine. Dit is veel dankbaarder werk omdat je dan echt een leuke oplossing kunt implementeren en tegelijk nog veel kan opsteken over grammatica's, de verschillende vormen hiervan en de verschillende parsing algoritmen

Dat lijkt me een zeer goed idee en zoals ik al gereplyed heb op je grote uitleg en moet bekennen dat ik nog nooit zoveel heb getyped op een reply denk ik dat wat gerichte literatuur geen slecht idee is, en verder wil ik ook wat boeken gaan aanschaffen die mij niet alleen voor dit soort dingen een breder kijkbeeld kunnen geven maar ook voor wat de toekomst allemaal te bieden heeft, want het ontwerpen van een goede parser kost goed denk werk en wanneer je een goede parser kan schrijven kan je niet alleen op het gebied van computers maar op zoveel gebieden veel meer

code:

Wieeeeeeew ik heb nog nooit zoveel getyped achter elkaar

[mbravenboer]

xtentic: Wat ik hier uit begrijp en hoop dat ik het goed is is dat een parser alleen zoals je al zegt een boom structuur maakt

Yepz, een grammatica (die over het algemeen context-vrij zijn voor programmeertalen, hoef je verder niet direct te weten) bestaat uit productie regels: een parser bepaalt hoe een string 'geproduceerd' kan worden door de productieregels toe te passen.

maar als ik naar je voorbeeld kijk zie ik eerst plus, en dan het gedeelte min, waaruit ik logischer wijs begrijp dat je 5 + - 6 - 2 lees, omdat min al voor de 6 staat...

Je hebt me helemaal goed begrepen, want met de gebruikelijke associativiteit van + en - (links) is mijn voorbeeld inderdaad volledig fout . De min moet inderdaad bovenaan staan: (5 + 6) - 2. +

code:

<Min>
   <Plus>
    <IntConst>5</IntConst>
    <IntConst>6</IntConst>
   </Plus>
   <IntConst>2</IntConst>
</Min>

Sorry voor de vergissing, best schaamteloos om zo'n fout te maken als je net een grammatica voor SQL gemaakt heb (met dus ook numerieke expressies ).

Overigens is het parsen van numerieke expressies zeer educatief: 5 + 3 * 2 is bijvoorbeeld geen (5 + 3) * 2, zoals dat bij de - wel het geval was. Juist voor deze situaties heb je kennis van grammatica's en productie-regels nodig.

ad-hoc?...

Een ad-hoc oplossing is een oplossing die misschien wel werkt, maar toch niet fraai is: niet goed opgezet, niet herbruikbaar (in het woordenboek staat "voor deze zaak, voor dit doel in het bijzonder"). Ook wel bekend als "dirty of quick hack" .

maar wat ik wel begrijp is gewoon dat je non syntax je template gaat parsen dus zonder extene informatie om het zo even te noemen.

Wat ik vooral bedoelde is dat de parser in dit geval niet gebouwd wordt met de structuur van de taal als handleiding. Er wordt dus gewoon een beetje geprogrammeerd met de gedachte "oh, hier kan dit en daar kan dat". Typische gevallen waarmee zo'n aanpak volledig faalt is bijvoorbeeld een quote in een quote enz...

Begrijp ik goed dat dit eingelijk wijst naar het gene dat ik al heb gemaakt?, want deze heeft een 'standaard' gramatica en parst deze gewoon weer naar html output zoals het ook in de 'template' vermeld staat maar dan met de veranderde delen.

Ik doelde denk ik toch op een nog gestructureerde aanpak, met een echte grammatica voor de taal en niet een 'standaard' grammatica ('vanzelfsprekende' grammatica). Eigenlijk moet je denken aan concrete productie-regels. Hiermee krijg je te maken met allerlei grammatica technieken en enge termen als non-terminals, terminals en dergelijke. Het kan echter wel erg nuttig zijn om je hier eens in te verdiepen als je dergelijk werk leuk vindt.

Het voorbeeld zoals je vermelde leek idd erg veel op XML, maar xml wordt ook geparsed voordat het de gebruiker bereikt dus verdubbel je dan de parser van 1 parser naar 2x parsen?...

XML is in feite een concrete syntax voor Abstracte Syntax Trees (eigenlijk in het algemeen bomen, om precies te zijn reguliere bomen). Omdat deze boom bij XML echter wel weggeschreven is als een string moet deze toch nog eerst geparsed worden. Dit kan echter gedaan worden door een parser die alle XML documenten aan kan: generiek voor alle documenten in de taal XML. Als de parser klaar is, heb je gelijk een soort abstract syntax tree in handen.

Tuurlijk en zoals ik al vermelde is XML ook al geparsed en dus minder leuk als uitdaging , het is voor mij persoonlijk een leerweg, ik speel al ruim 6 jaar met websites en dat begon met het parsen van een template in QuickBASIC naar een gewone HTML pagina maar zoals de tijd doorgaat moest ik ook door en wil nu de weg in staan van PHP.

Ok, als je zelf meer van parsen wilt leert is dat natuurlijk heel erg leuk, maar probeer niet alles zelf te ontdekken: dat kan namelijk gewoon niet. Je moet echt even wat toegankelijk literatuur opzoeken en minstens leren wat talen, grammatica's en productie regels en lexers zijn. Ook moet je eens werken met een parser-generator.

Dit begrijp ik niet, het is toch leuk dat meerdere mensen gaan spelen met een taal en zo proberen hun eigen dingen te maken/crearen...

Tuurlijk het is harstikke leuk als mensen hier zelf mee aan de slag gaan, maar het ontwerpen van een XML achtig iets vind ik persoonlijk minder zinvol. Ik denk dat het dan nuttiger is om te kiezen voor echte concrete syntax of anders gewoon XML te nemen.

Voor zover ik het nu doe is het denk ik met oplossing 1, ik genereer gewoon de zelfde code als UBB codes maar dat werkt nog niet zoals ik het wil hebben, oplossing 2 is echter voor mij wel te doen maar vergt veel meer ervaring en kennis dan dat ik nu heb en voor oplossing 3 zie ik het somber in

Het grappige is dat oplossing 3 verreweg het makkelijkst is. Een parser generator doet al het werk voor je en bovendien op een nette manier. Het is veel ingewikkelder om een parser te schrijven dan om er eentje te genereren uit een grammatica. De vervelende eigenschap van veel programmeurs (inclusief mij) is echter dat ze nooit willen lezen en zelf aan de slag willen. Dit lijkt makkelijker, maar meestal kom je na wat leeswerk juist op een makkelijkere oplossing. Als je serieus met parsen bezig gaat moet je gewoon kennis hebben van grammatica's.

Oplossing 2 is een goede keuze als je veel kennis van parsers op wilt doen, maar vereist meer kennis dan het generen van een parser.

Je bedoeld als je de template geparsed hebt naar een soortement grote array (tree). Dat is zoals ik al vermelde in mijn geval denk ik wel een zeer grote opgave behalve als we het over XML gaan hebben.

Je parsed inderdaad naar een soort boom-structuur. Vergis je echter niet: het direct interpreteren van je templates is veel moeilijker dan het opbouwen van een boom-structuur. Je moet je probleem zoals ik op de eerste regel al zei verdelen in twee onderdelen: parsen, evalueren. Jij doet het in feite tegelijk en dat maakt het werk alleen maar veel ingewikkelder.

Dit begrijp ik nog niet evenals het idee van ZEND dat je je data kan versleutelen en dan nogmaals kan compileren door PHP.

Tja, jij schrijft toch PHP? Waarom zou een tool dan geen PHP kunnen genereren?

Dat parsers het systeem trager maken is mij idd al bekend, maar dat het zoveel zou uitmaken niet

Het gaat hier eigenlijk niet om het parsen, maar het evalueren van de template. Jij doet dit tegelijk, wat lastig is. Als je dit verdeeld in twee componenten is compilatie de vervanging van de interpretatie van de boom. PHP moet ook geparsed worden, dus daarvoor is het eigenlijk geen vervanging (behalve dat de PHP parser vast sneller en beter is dan een eigen parser).

idd, maar hoe zou dat dan te controlleren zijn?

Als jouw template engine PHP code oplevert 'compileer' je de template in feite. Het resultaat is PHP en dat kan je gewoon bekijken en uitvoeren. Dit is dus juist uitstekend te controleren. Een interpretatie methode kan niet bekeken worden: die moet je uitvoeren.

Verder zal ik gaan spacen op XML

Ik begin oud te worden: 'spacen' is nieuw voor me .

al wil ik toch wel proberen mijn parser eerst NON XML te houden omdat ik op die manier PHP nog beter onder de knie kan krijgen alsdat ik het nu heb.

Dat is op zich een prima aanpak. Wees echter niet te bang voor dingen die nieuw en moeilijk lijken zoals bijvoorbeeld een grammatica en een parser-generator. Als jij ze eenmaal beheerst zal je je voor je kop slaan dat je er niet eerder naar gekeken hebt . Het is echt de moeite waard om tijd te steken in het lezen over de ideeen en methoden die al ontwikkeld zijn.

dit zal echter door mijn eigenschuld (gekapt met school ivm mooie werk aanbieding toen die tijd) gekomen zijn.

Tja, kappen met school is inderdaad niet verstandig, maar daar ben je zelf al achter ....

Wieeeeeeew ik heb nog nooit zoveel getyped achter elkaar

Dat krijg je ervan als je met mij gaat praten .

Nogmaals vriendelijk bedankt.

Graag gedaan hoor .

[Verwijderd]

Ik denk dat we hier nog wel uren over na kunnen praten en dat zou in mijn geval heel handig zijn, maar heb niet echt de puf meer over om dat van je te gaan verlangen, het enigste dat ik je nog wil vragen is wat leesvoer, boeken, links, tips etc ...

Ik ben zelf een 'doe het' leerder, ik moet het doen voordat ik het leer, met veel oefenen en op me bek gaan leer ik en vooral van voorbeelden ben ik erg afhankelijk, ik hoop dat je naar iets kan refereren dat veel voorbeelden, etc bevat ..

Mijn dank is groot.

[Verwijderd]

contect vrij? *hoort belletje*

heb vandaag tentamen Automatentheorie en Formele Talen gehad... hehe, heb 3 van de 10 vragen ingvuld, me boek noggis doorlezen!!

misschien dat je um kent:
Peter Linz - An Introduction to Formal Languages and Automata

edit:

En dan vooral het stuk over formele talen of course
vanalles over de beruchte boomstructuren et
pushdown automata
Turing machines as Language accepters etc

[mbravenboer]

xtentic: leesvoer, boeken, links, tips

Ik weet eigenlijk niet goed wat ik je moet aanraden.... Compilers, Principles, Techniques and Tools van Aho & zo is een killer, maar ik denk niet dat ik je dat aan moet doen. Modern Compiler Implementation in C|Java|ML van Appel is ook best wel goed, maar ik denk eigenlijk dat dat ook te snel gaat. Helaas weet ik dus zo geen introducerend materiaal wat eenvoudig genoeg (meeste parsing tekst die ik gelezen heb staat toch in compiler boeken), maar misschien dat anderen iets weten.... Alarmnummer zit ook in de parser-generator en grammatica toestanden ... Ik zal hem even hierop wijzen, misschien dat hij een goede tip heeft .

[mbravenboer]

zellufs: contect vrij? *hoort belletje*

Zozo, dat schiet al aardig op dan . Heb je ook al geleerd dat vrijwel alle parser-generators geen context-vrije grammatica's aan kunnen?

Peter Linz - An Introduction to Formal Languages and Automata

Ik ken hem niet.... ff zoeken op Amazon naar de index...

http://www.amazon.com/exec/obidos/ASIN/0763714224

Hum, die kopers zijn er niet bepaald enthousiast over . Deze ziet er een stuk beter uit, maar lijkt mij veel te zwaar materiaal:

Introduction to Automata Theory, Languages, and Computation (2nd Edition)

[Verwijderd]

Mag ik vragen over wat voor een boeken dit gaat? Het ontwerpen van een product ofzo?

[Verwijderd]

Dat peter linz boeken moesten we voor school hebben (1e jaar Informatica TU/e)...

Maar het gaat over formele talen (en uiteraard dus language accepters, parsers e.d.)

[mbravenboer]

int: Mag ik vragen over wat voor een boeken dit gaat? Het ontwerpen van een product ofzo?

De boeken gaan over talen (programmeertalen in het bijzonder), de specificatie van talen in grammatica's en het parsen van 'zinnen' in deze talen.

Elke programmeertaal (nou ja, elke degelijke programmeertaal) is beschreven met een grammatica. Dit is vaak de specificatie van de taal en je kan er ook een parser voor deze taal uit genereren.

[mbravenboer]

Zie deze oproep op Javahova (waar merkwaardig genoeg nogal wat parser en programmeertalen geeks zitten )

Parsing: introducerend materiaal

Tot nu nog niet echt een geschikte bron, maar wat niet is kan nog komen .

[Verwijderd]

Ik heb het topic ff gelezen, en moet zeggen dat ik het fijn vind dat mensen zo aan me denken maar moet ook zeggen dat er weinig nuttigs uit is gekomen, ik ga vandaag ff verder kijken in de stad en hopen dat ik een nuttig boek kan kopen

Nogmaals bedankt.

[Verwijderd]

Ik vond het zonde om hier een nieuwe topic voor te openen en ik wist even niet waar ik hem bij zou kunnen zetten, maar ik wil even weten of dit (in pcre dus)

code:

/\\[\/?[a-z]+(( [a-z]+ ?= ?"?[^"\]]+"?)*)\]/ise

een goede fomrulering zou zijn van een tag die voldoet aan de volgende eisen:
eerst een [
dan een mogelijke / (voor de sluittags)
dan een woord (alleen letters dus)
daarna OF een ] of argumenten

waarbij een argument voldoet aan:
eerst een spatie,
dan een woord,
dan een mogelijke spatie,
dan een =
een mogelijke spatie,
misschien een " (niet verplicht)
dan de waarde van het argument, deze waarde kan bestaan uit alles behalve een ] of een "
dan weer een mogelijke "

tags kunnen dan bijvoorbeeld zijn:
[div]
[/div]
[b]
[img w="45" h=456 b = "67";

etc...

is deze formulering daarvoor afdoende, of zijn er uitzonderingen te bedenken

nóg een vraag, zijn er richtlijnen voor de tijd waarin de parser een bepaalde grootte tekst geparsed moet kunnen hebben?

[mbravenboer]

zellufs: Ik vond het zonde om hier een nieuwe topic voor te openen en ik wist even niet waar ik hem bij zou kunnen zetten, maar ik wil even weten of dit een goede fomrulering zou zijn

De regex kan misschien best goed zijn (niet gecontroleerd), maar de notatie is waardeloos. Dit kan je veel beter noteren in een context-vrije grammatica. Reguliere expressies zijn bedoeld om kleine literal-achtige stringetjes te matchen: niet complete talen.

In het Syntax Definition Formalism (SDF) zou je definitie er zo uit zien. Ook ik heb geen rekening gehouden met het escapen van character, maar in tegenstelling tot de reguliere expressies oplossing is het hier vrij eenvoudig toe te voegen.

SDF gebruikt modules, wat erg fijn werkt. Hier ze je de whitespace module. Deze kan je eigenlijk over hergebruiken.

code:

module WhiteSpace
exports
  lexical syntax
    [\ \t\n] -> LAYOUT

  context-free restrictions
    LAYOUT? -/- [\ \t\n]

Je ziet hier gespecificeerd dat spaties, tabs en newlines layouts zijn en dat layout de 'longest-match' gebruikt: na layout mag geen layout komen.

Dan een belangrijke module waarin ik identifiers, tokens en stringschars specificeer:

code:

module Lexical
exports
  lexical syntax
    [a-zA-Z][a-zA-Z0-9]*  -> Identifier
    ~[\ \t\n]*      -> Token
    ~[\"\\]*          -> StringChars

  lexical restrictions
    Identifier -/- [a-zA-Z0-9]
    Token   -/- ~[\"\ \t\n]

Zoals je ziet specificeer ik dat een Token geen whitespace mag bevatten, maar verder elk teken. Dit is belangrijk voor het attribuut zonder quotjes, waar dus alleen tokens achter mogen staan.

Verder specificeer ik identifiers, wat de identifiers zijn zoals je die in de meeste talen ziet en StringChars wat geen quotes of back-slashes mag bevatten.

Dan blijft er nu nog meer heel weinig werk over:

code:

module Main
imports WhiteSpace Lexical
exports
  sorts Element Attribute StringLiteral
  context-free syntax
    "[" Identifier Attribute* "]" -> Element     {cons("Element")}
    Identifier "=" StringLiteral  -> Attribute     {cons("Attribute")}

    "\"" StringChars "\""  -> StringLiteral {cons("String")}
    Token           -> StringLiteral {cons("String")}

In deze module specificeer ik een 'Element' als iets wat begint met een "[", gevolgt wordt 0 of meer attributes en afgesloten wordt met een "]". Attributes zijn Identifiers, gevolgd door een "=", gevolgd door een StringLiteral wat dus een token of een gequote tekst mag zijn. De "cons" dingen achter de productie-regels geven aan wat de namen van de productie-regels zijn. Deze worden gebruikt bij het maken van de boom.

Ik heb een paar tests gemaakt:

code:

[test]

wordt:

Element("test",[])

[] is de lege leest: geen attributen, "test" is de naam van het element en "Element" is de naam van de productie-regel die ik opgegeven had met "cons".

code:

[test width="10"]

wordt:

Element("test",[Attribute("width",String("10"))])

en tot slot:

code:

[test width=10 height="50"]

wordt:

Element("test",[Attribute("width",String("10")),Attribute("height",String("50"))])

Tja... werkt netjes he? . Je ziet gelijk wat leuke voorbeelden van bomen.


Zoals ik altijd al gedaan heb, pleit ik er dus weer voor om reguliere expressies alleen te gebruiken waarvoor ze bedoeld zijn: eenvoudige pattern matching van literals. In Perl 6 krijg je een aantal interessantere features waarbij je het toch nog op een hele fraaie manier kan doen zoals ik het in dit voorbeeld ook ongeveer heb gedaan, maar de huidige methoden om complete talen met reguliere expressies te gaan parsen is echt ontzettend fout.

Ik verwacht niet dat jullie nu gelijk allemaal naar SDF of een andere grammatica taal/parser-generator vliegen, maar je hebt in ieder geval gezien dat het makkelijker kan (ondanks dat de syntax die ik gebruik en het hele fenomeen grammatica's natuurlijk nieuw is).

Als je de code inclusief Makefile wilt hebben kan ik die online zetten en als iemand misschien ook XT wil installeren om hier eens zelf mee te spelen, wil ik je graag helpen .

nóg een vraag, zijn er richtlijnen voor de tijd waarin de parser een bepaalde grootte tekst geparsed moet kunnen hebben?

Mwah, gewoon zo snel mogelijk .

[Verwijderd]

Woehoe!
Ik zal er me eens in gaan verdiepen, het enige probleem is eigenlijk dus dat het voor mij toegepast moet worden in PHP...

Maar daar zal ook wel wat op te vinden zijn neem ik aan. Ik zal eerst eens flink wat over grammatica's enzo gaan lezen, bedankt tot zover iig en je hoort binnekort wel meer waarschijnlijk

edit:

Ennum , zettem maar ergens online ast kan

[mbravenboer]

zellufs: Ik zal er me eens in gaan verdiepen, het enige probleem is eigenlijk dus dat het voor mij toegepast moet worden in PHP...

Voor andere talen als Java/C/C++ zijn er bergen parser-generators, maar voor PHP weet ik dat niet... Als het een linux/unix systeem is en je de vrijheid hebt is het op zich geen probleem om toch van de XT tools gebruik te maken.

Ik zal eerst eens flink wat over grammatica's enzo gaan lezen

Dat lijkt me wel een goed idee . Als je af en toe ziet wat hier langs komt aan 'reguliere expressies' schieten de tranen je in de ogen: ongeveer zoiets als me een tandenborstel de stoep schoonmaken .

Ennum , zettem maar ergens online ast kan

Voila: http://www.pandoramix.org/software/tags.tar.gz

Om het te kunnen draaien moet je wel XT installeren (en daavoor weer een Unix/Linux/Windoos met Cygwin/MacOS X computer).

[Verwijderd]

Ik zie dat ik beter eerst maar eens wat grote boeken moet gaat doorspitten, want de laatste paar postings gaan gewoon echt boven me petje

[Verwijderd]

Had Cygwin er net weer afgehaald maar ok... ben het zootje aant downloaden...

edit:

Geïnstalleerd, nu ff lezen