![]() |
Tänkte bara skriva ett par rader och tipsa de som ännu inte använder XSLT att ta en titt på det. Funkar utmärkt i en MVC-struktur, och är riktigt mysigt att arbeta med. Det enda trista är PHPs begränsning att bara kunna använda XSLT 1.0, och inte 2.0 som kom ut nyligen. Men det är ju inte en svaghet i XSLT, utan i PHP. Kort och gott: XSLT ftw.
Någon som delar min uppfattning, eller motsätter sig å det grövsta? :) |
Ser inte riktigt vitsen med det? Plus att det verkar enormt krångligt.
|
Det är kanske en liten tröskel att komma in i det, men när du väl klättrat över den tröskeln så är det hur smidigt som helst.
Fördelen är ju att det kvittar vad du har för controller, vilket språk systemet skrivits i osv, bara det genererar XML-output. Det betyder att du i framtiden om du vill byta motor (från PHP till Java exempelvis) "bakom" sidan inte behöver byta ut viewlagret. Du är ju dessutom inte bunden till att skapa html med XSLT. Kanske ska företaget sätta ihop en folder, pdf, eller liknande, då kan XSLT komma väl till pass och rendera dessa utifrån de redan existerande xml-källorna. |
Du glömmer bort buggarna som finns i det, sist jag lekte med XSLT så slutade det med att MSIE visade XML bladet.
|
Citat:
Det beror ju på om du väljer att göra transformeringen i webbläsaren eller på servern. Jag låter alltid servern transformera. Varför skulle jag låta klienten få tillgång till all data i XML:en? Så som var till det så tror jag helt enkelt att du använde det fel :) |
XSLT är riktigt smart. Användbart särskilt i de fall som samma data ska visas på flera ställen men med olika formateringar. Dessutom kan man också med samma datakälla leverera en massa olika output: html, rss, atom, csv osv osv
|
Blir enklare att använda olika smarty-templates (eller motsvarande) för att få olika formattering på samma data om man använder template-system med det än XSLT, som är otroligt krångligt i min mening. Syntaxen är ju ett riktigt eye-sore.
|
En ganska intressant artikel där Smarty jämförs med XML/XSLT: http://www.devpapers.com/article/18
Jag saxade slutsatsen: As a conclusion, we want to tell that it is basically a matter of preference on whether to use Smarty (or any other template “engine”) or XML/XSLT, as both the two major methods have their pros and cons. In some cases, it is better to use Smarty, especially if you do not have full access to your server and cannot compile XSLT support into PHP. In many other cases, the power and flexibility of XML/XSLT beats Smarty (and other dozens of currently available template “engines”) easily in most of the aspects of its usage. Diskussionen är intressant. :) |
Jag ser XSLTs främsta styrka som att man enkelt kan flytta data mellan olika former av XML samt att man då möjligen kan formattera det till HTML i browsern (tex på RSS-feeds) helt sömnlöst. Dock verkar färre och färre browsers stödja det nu, märker att det bara är IE (av de browsrar jag testat i) som fortfarande bryr sig om mina RSS-XSLT-stylesheets.
|
FF stödjer XSLT.
Men jag ser som sagt att styrkan inte ligger i klient-stödet, utan i serverside transformering. |
Jobbar man objektorienterat är det grymt att serilisera ett objekt (till xml) och sedan bara lägga på ettt xslt för att få det att se snyggt ut.
|
Citat:
Det är ingen vidare nytta med att använda det i webbläsaren men det fungerar utmärkt för att förstärka separationen av innehåll, utseende och funktion. Omåttligt smidigt för att exempelvis generera skilda html- och text-mejls från en fil - du behöver aldrig fundera på om det är olika innehåll i text- och html-filen. Eller du har äntligen kommit på hur ett html-mejl ser bra ut i alla mejlklienter - skapa en xsl-fil och du behöver bara mata den med xml-filer enligt någon dtd och kan vara säker på att det alltid ser bra ut. Eller du har en sajt med 19 språk men bara en html-sida att ändra i eftersom den genereras med xsl - utan att behöva underhålla 19 egentligen likadana html-sidor (makalös frustrationsbesparing). Samma sak kan göras med serverskriptspråk men inte utan att man får plottriga skriptsidor där text, innehåll och kod går om varannat - och vid varje för ändring riskerar man felmeddelanden (som kan vara ett rejält avbräck för viktig sida). Bara en sådan sak som att man bara kan skicka iväg ett xml-dokument för översättning och sedan validera mot dtd:n och direkt sätta in i en applikation utan risk för skriptfel eller trasig applikation är ganska mycket värt. Det enda man kanske kan invända är att det kan vara lite snårigt att lära sig om man har dålig koll på xml. Semantisk xhtml, css, xml, xsl, xpath, sql och oop-serverskriptspråk är framtiden redan nu. |
martine, du sätter ord till mina tankar. Tack för det :)
|
Nån som kan länka till någon bra guide för XSLT? W3schools guide suger ju.
|
Om något är intresserad så är xslt.se till salu här på wn i Köp och Sälj.
|
Alla tider är GMT +2. Klockan är nu 21:13. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson