Mint a cím is mutatja leginkább weboldal enginekről lesz szó, ahogy én képzelem. Az alap probléma, ami az engineknél közös, hogy a szerver oldalról nyert információt egyrészt hogyan, másrészt milyen átalakításokkal juttassuk el a felhasználóhoz úgy, hogy az végül html(mostanság xhtml) formába kerüljön. Az első kérdés amit egy enginenél le kell szögezni, hogy milyen böngészőkön kell annak működnie, ez határozza meg, hogy milyen technológiákat lehet alkalmazni az oldalon. Ha dinamikus oldalról van szó, akkor a két lehetőség a flash és az ajax, ha pedig statikusról, akkor nyilván html.
Ez eddig rendben is van, viszont egy nagyon fontos dolog kimaradt belőle, ami igazából szerintem az ajaxban a legjobb dolog. Sok helyen azt hallja az ember, hogy ha ajaxszal dolgozik, akkor érdemes jsonnal küldeni az adatokat, és végül a kapott adatokat javascripttel átalakítani, kiíratni. A kiíratásra két módszer van konkrétan:
Az egyik a DOM
var books=
[
{title: "XML kézikönyv", author: {firstname: "Neil", lastname: "Bradley"}, date: 2005},
{title: "Ajax a javascript ereje", author: {firstname: "Nándor", lastname: "Kolman"}, date: 2007},
{title: "PHP haladóknak", author: {firstname: "Peter", lastname: "Moulding"}, date: 2002}
];//a kapott adat
var content=document.getElementById("cid"); //ide jön majd a tartalom
var br=document.createElement("br");
for (var i=0; i<books.length;i++)
{
var book=books[i];
var title=document.createElement("span");
title.innerHTML=book.title+" in year "+book.date;
var author=document.createElement("span");
author.innerHTML=book.firstname+" "+book.lastname;
var container=document.createElement("div");
container.appendChild(title);
container.appendChild(br.cloneNode(false));
container.appendChild(author);
content.appendChild(node)
}
, a másik pedig az innerHTML:
var books=...;
var content=...;
for (var html="",i=0; i<books.length;i++)
html+="....";
content.innerHTML+=html;
Ezek közül az innerHTMLes megoldás a gyorsabb, a DOMosat is fel lehet pörgetni cloneNodeval, ha ügyesen csináljuk, viszont akkor is picivel lassabb lesz, mint az innerHTML. Szóval még mindig úgy állunk, hogy érdemesebb lenne html-t áthozni, és azt innerHTMLel kiíratni. És igazából ez az, amerre én is elindultam. A másik ok, ami miatt ezt választottam, hogy nagyobb tartalomnál, ahol nem egységes a struktúra, mint mondjuk például egy cikk, ott a json nem a legjobban elkalmazható módszer. Próbáltam eleinte kifejleszteni Javascriptben egy átalakítót, ami például object-treet(faszerkezetet) képes objectből innerHTMLbe alakítani, és úgy kiíratni. Ennek során akadtam egy core javascript bugra a firefoxban:
var prototype, x;
function Bug() {
var func = function () {
x;
};
prototype;
}
alert(
"Bug: "+ !(new Bug instanceof Bug)
);
Az volt a célom, hogy létrehozok node típusokat, és azokhoz átalakító függvényeket rendelek, majd miután elkészültem a node típusok meghatározásával beletöltöm az adatokat. Ennek a modulnak a kialakítása során alkalmaztam hasonló szerkezetet, mint a fent látható, és így azt kaptam, hogy a típus nem típus, szóval nem működik rendesen az instanceof függvény a firefoxban. A hibát jelentettem, nemrég írtak rá fixationt a fejlesztők, szóval firefox 3.0-ban már javítva lesz a dolog.
Ez az egész egy javascript programozási kérdést vet fel. Konkrétan arról van szó, hogy a prototype név használata produkálta a hibát, viszont ez nem fenntartott szó, hanem a syntactic keywords csoportba tartozik, tehát elvileg lehetne használni. Ezek után úgy gondolom, hogy nem érdemes olyan programot írni, ami javascriptes kulcsszavakat használ, és ezt javaslom nektek is.
A hiba ellenére nyilván elkészült a script is, közben viszont megtaláltam a legoptimálisabb megoldást az alap problémára, – ami nevezetesen az, hogy ajaxal csak adatot szeretnék küldeni a külalakot pedig felhasználó oldalon kialakítani az engine segítségével – a megoldás pedig nagyon egyszerű, és olyan kézenfekvő miután kicsit foglalkozik vele az ember, a neve pedig XSLT.
A JSONos átalakító modulomnak ugyanaz a funkciója, mint XMLnél az XSLTnek, viszont az XSLT egyrészt gyorsabb, másrészt többet tud, és ami a legfontosabb: körülbelül 2000 óta támogatják a böngészők. Másrészt az oldal más formára hozásához csak másik XSL fájlt kell megadni az XMLben stíluslapnak, amit a szerver oldali nyelvvel bármikor beállíthatunk. Tehát így ugyanazzal az XMLel RSS feedet, statikus oldalt, ajaxos dinamikus oldalt tudunk létrehozni, attól függően, hogy az adott böngésző melyiket képes megjeleníteni ezek közül, vagy a felhasználó mit szeretne. És ami legszebb az egészben, hogy felesleges innentől a [bbcode], mert XML formában lehet adatokat feltölteni, ezeket az adatokat pedig egy a felhasználó jogosultságának megfelelően állítható XSL fájl alakítja olyan formára, ami a szerveren mentve lesz, mint például cikk, hozzászólás stb. Ha pedig az adatforgalmat tényleg minimumra szeretnénk venni, akkor érdemes XML-JSON átalakítót írni a csomagoláshoz. A témáról még rengeteget lehetne beszélni, a lényeget azt hiszem leírtam, és szerintem hamarosan el fog terjedni a client side XSL, mert nagy jövője van.
Laci
Ezt érdemes még megnézni, mert valami hasonló módszert alkalmaznak a demoikban, mint amiről beszéltem, ők viszont szerver oldalon csinálják az xhtmlt, viszont a fájlok kiterjesztése xml, ami szerintem magáért beszél
Ha valaki tud németül.
Annak idején én is megszívtam ezzel a “milyen böngészőn működjön” kérdéskörrel. Megírtam responseXML-re egy http://digg.com/spy -hoz hasonló live oldalt, és utána kellett rájönnöm, hogy ezt az IE6 nem igazán tolerálja.
Hát igen, az egyedüli ok, amiért nem xhtmlt használok az ie6. az XSL viszont működik ie5től, szóval azzal nincs para.