Wat is XSL?
XSL is een opmaak taal voor XML bestanden. Met XSL kun je van de ene opmaak naar een andere opmaak. Een voorbeeld is <reactie>hoi</reactie> naar XHTML om te zetten als <div class="reactie">hoi</div>.
Waarom is dit handig?
Met XSL hoef je maar een keer een opmaak voor een 'tag' op te geven. Een reactie zal altijd als het divje hierboven worden omgevormd. Het betekent dat de inhoud van de opmaak is gescheiden. En gaat dus een stapje verder dan CSS. Doordat de opmaak van Fok altijd hetzelfde is (per template) kan dus voor alle topics met slechts een bestandje worden volstaan. Binnen dit topic wordt ook maar een keer de vormgeving van een reactie 'opgemaakt', immers alle reacties zien er hetzelfde uit. Dat scheelt bandbreedte en browser tijd.
Argumenten tegen:
- Als het fout gaat, gaat het goed fout. Je ziet een foutmelding in je browser, dat de browser er niets van snapt.
- Het doel is om naar 'statische' bestanden te gaan, maar wat doe je met dingen die (vaker) kunnen wijzigen tussen een topic. Denk bijvoorbeeld aan profiel informatie als 'subtitel' en 'onderschrift'.
- Een aantal mensen voeren in het vorige topic aan dat het er veel complexer op wordt.
Heb je een voorbeeldje voor me?
http://kinkrsoftware.nl/contrib/fok/topic.xml
en
http://kinkrsoftware.nl/contrib/fok/kinkrforum.xsl
vormen samen: (uitvoer via xsltproc)
http://kinkrsoftware.nl/contrib/fok/output.html
Leuk joh, maar dat is nog niet 1:1 fok.
Klopt, ik ben zeker geen goede DHTML/CSS man, dus als je zin hebt om de vormgeving van slechts 1 reactie tiptop te maken. Maak dat dan gewoon in HTML en plak het in dit topic. Je mag het natuurlijk ook mailen.
Okee, wat is er nodig om FOK! zo te laten draaien?
Danny, Breuls en anderen moeten worden overtuigd dat dit echt beter is. En dat het de database load naar beneden haalt. Vervolgens moet er uit SQL XML bestanden worden gemaakt analoog aan wat nu als voorbeeldje beschikbaar is.
En wat gebeurd er dan als ik een reactie wil schrijven?
In principe zou dat gewoon via een quick reply onderaan de pagina kunnen gaan die een post doet naar het Fok forum.
Maar Breuls/Danny/Iteejer/Highlander/Yvonne heeft gezegd dat het er niet komt, maar ik vind het toch een goed idee wat te doen?
Opzich kun je zelf XML bestanden maken op basis van de light layout door de javascriptcode te parsen en encoding problemen op te lossen. Je kunt vervolgens browsen met de XSL template.
Huidige problemen
- Het XML document bevat in de reply tag een xmlns. Als die er niet in staat gaat Mozilla op z'n snaveltje. En wordt de XML die binnen de reply staat niet als HTML behandeld. Ik zou daar graag een betere oplossing voor willen dan in iedere reply een xmlns neer te zetten.
- Crisp meldde in het andere topic dat Internet Explorer nog steeds in Quirks mode draait. Daar zou een oplossing voor moeten komen zonder de XSL output weer terug te zetten naar HTML. (Deze staat nu op XML.)
[ Bericht 0% gewijzigd door Skinkie op 28-03-2008 02:14 ]
quote:DoneOp donderdag 27 maart 2008 21:11 schreef R-Mon het volgende:
Misschien leuk om het linkje naar het xsl bestand erbij te zetten? http://kinkrsoftware.nl/contrib/fok/kinkrforum.xsl
quote:Geen ideeOp donderdag 27 maart 2008 23:51 schreef Niox het volgende:
Als mooi argument voor: noem eens 10 websites van het formaat Fok (of groter) die een dergelijk systeem toepassen, en op die manier een significante performance winst boeken.
De XSL methodiek is een nog geavanceerdere statische webpagina implementatie. Dus je zou die vraag in tweeen kunnen splitsen naar:- Wie gebruiken er statische webpagina's? (Slashdot, Geenstijl/MT, Virtual Tourist)
- Wie welke sites publiceren een XML+XSL infrastructuur?
Ik weet dat de webinterfaces (embedded) van 3Com op XML/XSL combinaties draaiden, maar naar zo'n voorbeeld zoek je niet.
Maar goed, je vraag is valide, alleen zou een benchmark tussen een normale fok pagina en een XSL/XML fok pagina een veel beter inzicht geven.
quote:De vraag is natuurlijk verder nog waarvoor ze die statische pagina's gebruiken. Is dat voor alle (dynamische) content, of enkel voor veel opgevraagde pagina's die relatief weinig veranderen.Op vrijdag 28 maart 2008 02:08 schreef Skinkie het volgende:
- Wie gebruiken er statische webpagina's? (Slashdot, Geenstijl/MT, Virtual Tourist)
Ik ben in ieder geval nieuwsgierig!
quote:Het staat jezelf vrij een opsomming of overzichtjes te gaan maken, wie comments dynamisch of statisch host. Ik heb liever voorbeelden waarom het niet kan werken op een forum.Op vrijdag 28 maart 2008 12:42 schreef ACM het volgende:
[..]
De vraag is natuurlijk verder nog waarvoor ze die statische pagina's gebruiken. Is dat voor alle (dynamische) content, of enkel voor veel opgevraagde pagina's die relatief weinig veranderen.
quote:Zolang ik geen net voorbeeld van een werkbare omgeving zie is dat natuurlijk lastig om echt zinnige zaken te noemen die dan nog missen. Maar ik heb zo nu en dan al een paar dingen genoemd en noem hier wat punten die ik nu zo weet te bedenken:Op vrijdag 28 maart 2008 21:17 schreef Skinkie het volgende:
Het staat jezelf vrij een opsomming of overzichtjes te gaan maken, wie comments dynamisch of statisch host. Ik heb liever voorbeelden waarom het niet kan werken op een forum.
Een van de belangrijkere is denk ik nog steeds het simpele feit dat je bepaalde gegevens bij elkaar wilt/moet plaatsen die je domweg niet aan de client-side over mag laten. Integreren van privacy/ip-gegevens bij postings, bepalen of bepaalde forums zichtbaar zijn, etc. Dat zijn allemaal dingen die een behoorlijk fine-grained rechtencheck vereisen die vziw niet zomaar met http-authenticatie op te lossen is. Dat zorgt sowieso voor een verplichting om server-side te weten met wie je te maken hebt om te kunnen besluiten bepaalde gegevens wel of niet door te geven en mij is iig niet duidelijk hoe http-authenticatie je op dat detailniveau kan helpen. Sowieso wil je niet voor elke request de complete authenticatiedata meesturen, een redelijk onschuldig iets als een sessieid zou voldoende moeten zijn, en wil je dat gebruikers ook na het sluiten en heropenen van hun browser ingelogd kunnen blijven.
Buiten de privacy-data zijn de indexpagina en de active topics lijst nog voorbeelden waar dat heel sterk zal spelen.
Je hebt zelf verder al de koppeling genoemd tussen informatie die bij een topic aangeleverd wordt maar onafhankelijk ervan kunnen wijzigen, met name de userdata. Je wil natuurlijk niet dat je potentiele winst in renderingtijd teniet wordt gedaan doordat je een heleboel extra requests (met 304-results) moet uitvoeren alvorens te kunnen beginnen met renderen.
Verder heb ik nog niet gezien hoe je wilt voorkomen dat first-time-visitors en andere minder-regulire bezoekers lastig gevallen worden met enorme hoeveelheden (semi-statische) data, die ze bij elk bezoek zowat weer moeten verversen. Al is het alleen maar omdat hun browser-cache voor Fok door bezoeken aan andere sites en andere pagina's binnen Fok deels is overschreven.
Iets soortgelijks geldt voor de paginering. Je kan niet zomaar alle replies van een 250-reply topic naar iemand sturen als hij 25 reacties/pagina had ingesteld. Door je redelijk compacte xml is dat met 250 replies vs 25 nog relatief onschuldig, maar op GoT hebben we bijvoorbeeld ook topics van 1000-5000 replies. En juist dat soort topics lopen vrij hard, waardoor de kans groot is dat je steeds een paar MB aan data bij elk bezoek aan het specifieke topic opnieuw moet downloaden.
Of je moet een manier verzinnen om de pagina's in deelcaches op te slaan, maar dan loop je er weer tegen aan dat je cache-bijwerking complexer zal worden, omdat je ook van alle pagina-varianten moet checken of ze ververst of verwijderd moeten worden.
Een ander belangrijk punt - vanuit Fok gezien iig - is dat je bannering zal moeten kunnen ondersteunen en die bannering zal zeer waarschijnlijk niet met dom-methoden en andere xhtml-compatible technieken zijn uitgevoerd.
Verder is mij niet duidelijk waar je precies je caches van statische data wilt opslaan en hoe die - zeker indien verdeelt over meerdere servers - bijgewerkt zouden moeten worden op het moment dat er een wijziging plaatsgevonden heeft.
Wat dat betreft benader je het nu omgekeerd. Je wacht op tegenargumenten, terwijl je een compleet werkend forum voor je neus hebt hier waarvan de verwachting is dat een vervanging van de LAMP-structuur - door bijvoorbeeld jouw XML/XSL-variant - geen nadelige gevolgen heeft voor de functionaliteit en gebruiksvriendelijkheid.
Ik heb niet het idee dat uberhaupt iemand van Replique staat te springen om deze benadering, maar vanuit technologisch oogpunt kunnen we natuurlijk gewoon wat ontwerpen en implementeren.ps. Ik vraag niet per definitie om een eisenpakket van 'wat is een goed forum voor FOK!'. Maar ben toch benieuwd of als ik de problemen onderandere door jouw hierboven beschreven (eenvoudig) oplos, of je dan nog steeds zo sceptisch staat, of dat het dan door iedereen (weer) wordt afgewimpeld met 'leuk idee, we doen er niets mee'. Ik betrek graag wat mensen bij mijn ideeen.
quote:Vooral het laatste natuurlijkOp zaterdag 29 maart 2008 00:12 schreef Skinkie het volgende:
ACM wil je graag een design zien? Of iets dat werkt?
quote:Ik ben inderdaad behoorlijk sceptisch, maar probeer open minded je oplossing te benaderen. Echter heb ik tot nu toe een beetje de indruk dat je je op het makkelijke deel focussed (de xsl translatie) terwijl dat juist onder andere nuttig is als methode om een deel van de serverside-processing die je caching bemoeilijkt te omzeilen.Maar geef even een voorbeeld hoe ik bijvoorbeeld jou over de streep kan krijgen
quote:Het is nogal een drastische verandering, dus het moet echt aantoonbaar beter zijn, en niet op allerlei punten die nu goed werken complexiteit toevoegen, voor je een willekeurige organisatie kan overtuigen dat jouw manier de betere is. De kans is groot dat het dan alsnog afgewimpeld wordt omdat het te veel werk is en de huidige aanpak beter bekend is bij de ontwikkelaars. Zelf kan ik natuurlijk niet voor Fok spreken, maar enkel voor GoT/tweakers, maar ik heb nog niet de indruk dat de xml/xsl-aanpak met statische files de moeite van de tijd die het kost waard is. Maar dan speelt natuurlijk wel mee dat de performance bij tweakers.net en got niet echt een probleem is momenteel. En daarnaast is het natuurlijk maar de vraag in hoeverre de tijd die besteed zou moeten worden, aan een compleet andere aanpak, vertaalbaar is naar performanceverbeteringen in de huidige aanpak.ps. Ik vraag niet per definitie om een eisenpakket van 'wat is een goed forum voor FOK!'. Maar ben toch benieuwd of als ik de problemen onderandere door jouw hierboven beschreven (eenvoudig) oplos, of je dan nog steeds zo sceptisch staat, of dat het dan door iedereen (weer) wordt afgewimpeld met 'leuk idee, we doen er niets mee'. Ik betrek graag wat mensen bij mijn ideeen.
Voor mij is in ieder geval het verlies aan controle over waar bepaalde vertalingen uitgevoerd worden en het verlies aan mogelijkheid om ergens eenvoudig (rechten)checks en wijzigingen uit te voeren erg belangrijk. Maar het simpele feit dat de performance bij ons wel in orde is, zorgt er natuurlijk bij Fok ook voor dat ze weten dat de LAMP-aanpak ook hier wel moet kunnen werken en dat maakt jouw poging ze een andere weg in te laten gaan - die ze zelf niet erg goed kennen - er niet makkelijker op.
quote:"als hun het doen mogen wij het ook!"Op donderdag 27 maart 200823:51 schreef Niox het volgende:
Als mooi argument voor: noem eens 10 websites van het formaat Fok (of groter) die een dergelijk systeem toepassen, en op die manier een significante performance winst boeken.
Ultieme dooddoener natuurlijk
tevens verkapte tvp.
quote:Ik denk dat een xml/xsl setup sowieso niet snel geimplementeerd zal worden als je een (W/L)AMP stack als basis neemt. Voor .NET of java gebasseerde platformen wordt die insteek steeds vaker genomen. Onder tomcat of een echte webapp server is het drie keer klikken om een xsl webapp voor je standaard xml webservice laag te hangen. Onder .NET is de standaard caching laag weer veel uitgebreider heb ik mij laten vertellen.Op zaterdag 29 maart 2008 08:10 schreef ACM het volgende:
... zorgt er natuurlijk bij Fok ook voor dat ze weten dat de LAMP-aanpak ook hier wel moet kunnen werken en dat maakt jouw poging ze een andere weg in te laten gaan - die ze zelf niet erg goed kennen - er niet makkelijker op.
De vraag is ook even of in deze discussie het xml/xsl stuk inderdaad het belangrijkste is, of de caching insteek voor dynamische sites als deze.
quote:Zoals ik al eerder schreef is het aanbieden van XML/XSL slechts een verbetering op het serveren van statische content. Het argument dat het langer zou duren om een bestand te updaten (full html) gaat in beide situaties niet op. Immers als de reacties zo snel gaan dat per request een nieuwe HTML file de deur uit gaat, zou dat exact dezelfde performance moeten hebben.Op zaterdag 29 maart 2008 16:15 schreef Roönaän het volgende:
De vraag is ook even of in deze discussie het xml/xsl stuk inderdaad het belangrijkste is, of de caching insteek voor dynamische sites als deze.
Echter bij een site als deze kunnen we er vanuitgaan dat:
1) Er meer gelezen wordt dan gereageerd (feit: zie views)
2) Mensen terugkomen (feit: zie aantal ingelogde users)
Het uitbuiten dat er meer gelezen wordt kan door caching. Het uitbuiten dat mensen terug komen kan alleen door meer data hetzelfde te houden (en het dus cachebaar te maken).
quote:Voor FOK! denk ik dat je veel winst kan halen op niet ingelogde gebruikers in combinatie met deze opzet. Volgens mij kan je dieOp zaterdag 29 maart 2008 16:24 schreef Skinkie het volgende:
Het uitbuiten dat er meer gelezen wordt kan door caching. Het uitbuiten dat mensen terug komen kan alleen door meer data hetzelfde te houden (en het dus cachebaar te maken).
a) redirecten naar een andere database, zodat je member database ontlast wordt
b) simpelweg gecached (wel of niet xsl-based) meuk voor de kiezen gooien.
Qua caching weet ik alleen niet hoe sterk php daar an sich in is. File based caching zal wel okee gaan, maar zaken als gecompileerde XSL sheets ben ik voor php nog niet tegengekomen.
voor gasten zul je dit niet hebben, deze hebben allemaal de zelfde rechten. Ook maken ze gebruik van de standaard instellingen zoals hoeveel reacties per topic etc.
dan kun je toch heel makkelijk zeggen bij niet ingelogde gebruikers sturen we het topic in xsl voormaat en als je bent ingelogd krijg je een dynamische output zoals het nu is dus.
ik zeg ook maar wat, weet alleen niet of het handig is om met 2 soorten output te werken...
quote:Het zou natuurlijk primair gaan voor useragents die het wel aankunnen... en dat zijn al 99% van de browers. Voor die 1% die het niet accepteren kun je sowieso een oude layout aanbieden.Op zondag 30 maart 2008 12:54 schreef Roönaän het volgende:
Qua caching weet ik alleen niet hoe sterk php daar an sich in is. File based caching zal wel okee gaan, maar zaken als gecompileerde XSL sheets ben ik voor php nog niet tegengekomen.
Maar ook dit kan gebeuren door de webserver op basis de headers die door een client worden meegezonden.
quote:Nee, ze kunnen niet kiezen. Text-only agents krijgen de text-only en mobiele agents krijgen de mobiele layout. Alle andere niet-ingelogde gebruikers krijgen de baggerlayout met standaard instellingen.Op zondag 30 maart 2008 17:21 schreef Roönaän het volgende:
Kunnen "gasten" eigenlijk kiezen tussen layouts, anders dan dat de textonly op basis van hun useragent wordt gepushed?
Natuurlijk kunnen ze door de URL aan te passen de weergave wel tweaken, zoals het aantal p.p.p veranderen. Maar daar blijft het bij.
Ontopique: www.telemeter.be is ook met XML/XSL opgebouwd, maar da's statisch.
quote:Waarom eigenlijk? Zijn ingelogde gebruikers dus niet in staat om de layout te wijzigen op het moment dat hun User-Agent aan bepaalde condities voldoet?Op zondag 30 maart 2008 17:57 schreef HuHu het volgende:
[..]
Nee, ze kunnen niet kiezen. Text-only agents krijgen de text-only en mobiele agents krijgen de mobiele layout. Alle andere niet-ingelogde gebruikers krijgen de baggerlayout met standaard instellingen.
Natuurlijk kunnen ze door de URL aan te passen de weergave wel tweaken, zoals het aantal p.p.p veranderen. Maar daar blijft het bij.
- Momenteel heb ik iemand gevonden die 1 layout netjes in HTML gaat zetten
- Full Quick Reply achtigs komt onder ieder topic, waarbij de 'POST' naar het normale forum gaat via javascript
- Er is wat curl code beschikbaar gesteld
Wat nog te implementeren:
- Client-side opties (aantal posts weergeven etc.)
- Fetch scriptje op een 404
- Een scriptje dat op basis van actieve topics nieuwe data binnen haalt
ben je nou eigenlijk gewoon van plan een compleet werkende XML-template te maken en die zelf te hosten?quote:Doe even een traceje waar dat domein staatOp dinsdag 8 april 2008 22:58 schreef mcDavid het volgende:
Maar goed als het zou werken... dan is er binnen fok vast een Pentium III over om heel fok vanaf te draaien
De grootste winst (zoals verlichting van de server en minder dataverkeer) is natuurlijk te behalen, wanneer de transformatie wordt gedaan door de client. Veel implementaties die ik heb gezien, doen de transformatie op de server en sturen daarna alsnog de HTML op.
quote:Bron: http://en.wikipedia.org/wiki/XSLTAlthough client-side XSLT processing has been available in Microsoft's Internet Explorer since 1999 (or even earlier, but in a form that was incompatible with the W3C specifications), adoption has been slower because of the widespread deployment of older and alternative browsers without XSLT support. For similar reasons, adoption of XSLT 2.0 in such environments is likely to be some years away.
Kijk even welke browsers worden gebruikt door de meeste Fok! bezoekers en maak op basis daarvan een beslissing. Ik denk dat de meeste browsers dit inmiddels kunnen.
In principe wil ik hetzelfde doen als ik m'n eigen forum zou maken voor ingelogde gebruikers en instellingen. Maar dat kan voorlopig gewoon via javascript.
quote:Dat klopt. Als je User-Agent de googlebot is, krijg je altijd TO voor je neus. Is je User-Agent een mobile device, dan krijg je altijd de mobiele layout voor je neus.Op zaterdag 5 april 2008 11:10 schreef JeRa het volgende:
[..]
Waarom eigenlijk? Zijn ingelogde gebruikers dus niet in staat om de layout te wijzigen op het moment dat hun User-Agent aan bepaalde condities voldoet?
Dat is gedaan omdat over het algemeen mobiele browsers de standaard-layout van een gebruiker niet fijn vinden, die is er groot om te downloaden, veel bandbreedte en kost dus veel geld (beltegoed). Aangezien je niet kunt switchen van layout zonder eerst een layout voor je neus geschoteld te krijgen, wordt deze keuze voor je gemaakt door Replique.
Een wijziging in layout terwijl je via een mobiele telefoon surft is dus pas merkbaar op het moment dat je weer een niet-mobiel apparaat gebruikt.
quote:Als zelfs ik het kan begrijpen, moet nu iedereen het kunnen begrijpenmcDavid zegt (0:17):
Dus je hebt een database. Zoals nu de replique database. Die database is gewoon compleet. Altijd. En als je een post doet, wordt die rechtstreeks de database in geslingerd.
mcDavid zegt (0:17):
Die database wordt iedere 10 seconden gechecked op wijzigingen
mcDavid zegt (0:19):
Als blijkt dat een topic gewijzigd is, wordt hier een los xml-bestand van gemaakt. Dit wordt opgeslagen. Zodat je binnen no-time een hele rits statische bestanden hebt klaarstaan die heel snel opgevraagd kunnen worden.
mcDavid zegt (0:21):
Om het niet uit de klauwen te laten lopen, worden de losse xml-bestanden die langer dan (bijv) 24 uur niet bekeken zijn verwijderd. Als een user toch een topic dat langer dan die periode niet gewijzigd is op wil vragen, wordt er ter plekke een nieuw XML file gemaakt uit de database.
mcDavid zegt (0:22):
Maar er vanuit gaande dat 99% van de topics die opgevraagd worden jonger zijn dan die 24 uur (of hoe lang die periode ook mag zijn), heb je dus bijna altijd een topic klaarstaan.
mcDavid zegt (0:22):
En de database wordt eigenlijk alleen nog belast door die bot die iedere 10 seconden de boel update. En sporadisch een keer een user die een oud topic opgezocht heeft.
mcDavid zegt (0:23):
Heb ik zo het skinkie-plan goed samengevat?
quote:Uit onderzoek blijkt dat dit 36 uur is:Op vrijdag 11 april 2008 00:41 schreef mcDavid het volgende:
Maar er vanuit gaande dat 99% van de topics die opgevraagd worden jonger zijn dan die 24 uur (of hoe lang die periode ook mag zijn), heb je dus bijna altijd een topic klaarstaan.
Bron: http://physicsworld.com/cws/article/news/25291
Bron: http://www.nytimes.com/2006/07/17/business/media/17decay.html
quote:Het gaat hier om wanneer de eerste 50% van het totaal aantal 'te verwachten'-views zijn geweest.The average half-life of a news item is just 36 hours, or one and a half days after it is released.
quote:Zonder database toegangOp vrijdag 11 april 2008 20:42 schreef Roönaän het volgende:
Een 10 seconden bot is alleen wat knullig, daar zijn betere methoden voor. De key ligt echter niet direct in de caching op filesystem niveau, maar voornamelijk ook in het nuttige gebruik van je headers.
Tell me! (Ik weet dat Danny nog een ajax appje heeft...)quote:Correct... echter ik wilde zelf zo ver gaan dat ik alles wilde behouden totdat 90% van het geheugen vol zat en gewoon het minst bekeken item er direct uit knikkeren.Op vrijdag 11 april 2008 22:03
schreef mahlah het volgende:
[..]
Uit onderzoek blijkt dat dit 36 uur is:
Bron: http://physicsworld.com/cws/article/news/25291
Bron: http://www.nytimes.com/2006/07/17/business/media/17decay.html
[..]
Het gaat hier om wanneer de eerste 50% van het totaal aantal 'te verwachten'-views zijn geweest.
Wil best zelf een layout maken hoor, maar dat gaat meer tijd kosten denk ik.
en deze is ook nog niet helemaal af.
quote:Ik heb de linkjes in de topic start in ieder geval geupdate met 'dit' topic in xsl.Op zaterdag 12 april 2008 23:26 schreef mcDavid het volgende:
Ja hó effe, de layout is van danny, alleen de code is van mij!
Wil best zelf een layout maken hoor, maar dat gaat meer tijd kosten denk ik.
en deze is ook nog niet helemaal af.