quote:
Op maandag 24 maart 2008 00:45 schreef crisp het volgende:Een XSL translatie voer je uit op een XML-domtree, die inderdaad simpeler is dan een HTML-domtree, maar uiteindelijk moet die HTML-domtree ook gegenereerd worden. Dat dat per definitie sneller is durf ik wel te betwisten, onderbouw dat maar eens. IE speelt al vals want die bouwt sowieso al geen echte domtree op, daarom is dom-support ook zo spartaans en traag voor sommige onderdelen die ze wel ondersteunen dmv het faken van een echte domtree.
Okee stel dat je een document hebt van 100kb. Dit is een wellformed XHTML document. Om dit document te parsen moet je alle open en alle sluit tags af.
Setup twee heeft 100 replies. Honderd open en sluit tags. En 1 opmaak bestand waarin staat hoe 1 reactie er uit moet zien, laten we zeggen 10 tags.
In situatie 1 heb je dus de parse van minimaal 100*10 = 1000 tags. In situatie 2 heb je een parse van 100 tags + een parse van (met maximale overehead) 20 tags. Totaal 120 tags dus.
De XSL operatie is in alle gevallen efficiënt en is compleet pointer based. Zoals hierboven beschreven is:
1) Het inlezen van twee documenten sneller (in parse tijd)
2) Daar uitvolgend zou het combineren van de XSL template ook efficientere renders kunnen opleveren mits er voor de 'output mode' html een efficientere render strategie wordt gekozen. (Alles wat in het XSL document staat hoeft in principe 1x als render template klaar worden gezet)
quote:
Ik weet persoonlijk weinig van Monet dus daar kan ik weinig over zeggen. In hoeverre is dat een waardig alternatief voor een 'klassieke' relationele database en hoe verhoudt zich dat performance-wise voor verschillende veel voorkomende use-cases?
Het is zowel een klassieke relationele DB als een XML database (twee verschillende frontends). We gaan het nu niet over Monet hebben, dat haalt de focus weer compleet af van de voordelen van statische pagina's.
quote:
My bad, er zat wat tijd tussen het lezen en mijn reply dus ik had dat moeten verifieren. Maar dan komt wel een ander punt: jij gaat er dus blijkbaar van uit dat de omzetting van user-content gegarandeerd output oplevert die wellformed is. Ik ken eigenlijk geen enkele UBB-omzetter die XML-based is, laat staan in alle gevallen wellformed XHTML oplevert. XML blijkt voor de meeste programmeurs toch echt niet zo simpel te zijn als dat ze denken...
Op de encoding na is alles wat 'Replique' genereerde dus valide wellformed XHTML. Ik zou ook niet weten wat er verschillend zou zijn aan UBB als aan XML om strict te parsen. Maak je een fout... dan rendert het niet naar HTML, doe je het goed dan wel. In principe kun je voor UBB ook een XSL maken. (Die faalt of goed gaat)
quote:
Dat zijn twee UA's, maar je vergeet nog een hele grote: searchengines. Die zien alleen de ruwe XML-data; wat moeten ze daarmee? En voor de rest van de kleinere UA's heb je een gigantisch accessibility probleem.
Ook hier heb ik al een voorbeeld van gegeven. mod_xslt is bijvoorbeeld een apache implementatie om de pagina te renderen als de user-agent xml+xsl niet accepteert. In iedere header stuurt zo'n browser mee wat hij wel eet en wat niet, dat kun je ook gewoon gebruiken. Net zoals je dat voor gzip encoding doet. Gezien gzip nu gemeen goed is vraag ik me af wat xml tegenhoud voor de browsers die het ondersteunen.
Wat betreft searchengines, die doen momenteel toch al heuristisch zoeken. En je weet wellicht hoe 'semantic web' in elkaar zit, ik maak me er persoonlijk totaal geen zorgen over dat de google bot m'n site niet zou kunnen lezen.
quote:
Wat probeer je daarmee te bereiken dan? Als het eindresultaat niet aansluit op wat nodig is dan heb je er uiteindelijk toch niets aan?
Zoals Breuls het omschreef als "mooie vingeroefening". Als Fok het niet wil hebben omdat ze een superieure omgeving heeft blijven ze dat toch gewoon gebruiken
Er zal ooit wel iemand komen die denkt.... "mmm... leuk projectje gaan we wat mee doen".
quote:
Met alles wat je statisch maakt verlies je de mogelijkheid tot customisation, tenzij je meerdere versies gaat onderhouden en daarmee weer een stuk overhead genereerd.
Ook hoef je geen meerdere versies te onderhouden. In principe kun je de XSL stylesheet per sessie aanbieden. Daar is niets geks aan en dat gebeurd nu ook al op brede schaal. M'n sessie bepaald of ik ben ingelogd. Een sessie kan ook bepalen wel bestand ik krijg van een webserver. Op verschillende manieren. Ik ben van plan de authenticatie en gebruikersrechten van mijn forum met http-digest te gaan doen. Dus er is een sessie van webserver naar client en aan de hand van die sessie worden topics weergegeven of niet.
Zeker het laatste zal meer voeten in de aarde hebben, maar boven alles door de webserver zelf worden afgehandeld. Ik denk dat er brood in zit
quote:
Daarbij ben ik er niet van overtuigd dat een XML-based backend qua performance zoveel beter is.
Ik denk persoonlijk dat statische files beter zijn dan een XML database, daar dachten mijn docenten anders over. (Zeker gezien het updaten en verwerkingen op los te laten.) Dus een compromis kan zijn dat een update naar de database gaat, en de database een statisch bestandje per topic uitpoept. En dat als een topic x dagen niet wordt bekeken de bestanden automatisch met een cronjobje worden weggegooid.
custom menu