HTML5-re tér át a Dojo
A Dojo a JavaScript keretrendszerek közül leginkább azzal tűnik ki, hogy widget komponenseit deklaratívan, a HTML markupban is lehetséges konfigurálni bárminemű szkript programozás nélkül. Ezt a fejlesztők nem szabányos HTML attribútumok bevezetésével oldották meg, amiért rendre bírálat érte a projektet. (A jogosság megvitatásától itt most tekintsünk el.)
A HTML5 térnyerésével és a támadások ésszerű érveire hallgatva a Dojo az 1.6-os verziótól elhagyja saját attribútumait, és a HTML5-ös data- tulajdonságok használatára tér át. (A 2.0-s verzióig a régi attribútumok elavultaknak minősíttettek, támogatásuk pedig utána megszűnik.)
Egy Kivágás gombot Dojo < 1.6-tal így írnál:
<button dojoType="dijit.form.Button" jsId="toggleButton"
iconClass="dijitEditorIcon dijitEditorIconCut"
type="button">Kivágás</button>
Ezentúl pedig a szabványosság bódító mezejére lépve így is megteheted:
<button data-dojo-type="dijit.form.Button" data-dojo-id="toggleButton"
data-dojo-props="iconClass: 'dijitEditorIcon dijitEditorIconCut'"
type="button">Kivágás</button>
A váltás valamennyi saját attrítúbum névre vonatkozik.
■
Visszalépés?
Visszalépés
Szabvány
(Hogy mi hosszabb, és mi nem, én ebben sohasem tudtam érdemi vitapartner lenni, mert nem látom be, hogy miben másabb a
data-dojo-type-ot adojoType-hoz képest beírnod, engem a munkámban sohasem ez lassított, hiszen úgyis valami gyorsbillentyűhöz rendeled, snippetet írsz rá vagy a gépelés kiegészítő algoritmusra bízod.)Validator
Mert hülye és a saját szabványait sem támogatja. És igen, itt kezdődne a flame a DTD hiányáról meg az XML szaványról (nameg arról, hogy mi hogy (nem/rosszul) támogatja), de inkább nem megyek bele. Mindenki tudja miről van szó. Csakhogy a HTML5 a buzzword most meg a webalkalmazások ráerőszakolása egy arra alkalmatlan protokolra. De mindegy.
Másik problémám inkább még az, hogy az egészet nem visszafelé kompatibilisen oldották meg a HTML 5-ben.
Mármint mi nem visszafele
Picit félreérthetően fejeztem ki magam
És ha jól láttam, nem csak a HTML-l van probléma, hanem a JS-ben is mindenhol át kell írni pl a get/setAttributet is. forrás.
Az egész akkor lesz szép, amikor adott egy XHTML képességeit kihasználó rendszer és jön a megrendelő, aki közli, hogy márpedig HTML5 kell és nem lehet megértetni, hogy de nem.
Érdekes az attribute-os
Úgy, mint a PHP
Gondolom amiatt, hogy plusz adatokat lehet így egy elementhez hozzárendelni, emiatt adathazlmaz.
Tudtommal az XHTML-ről való
"átírását"
A doctype és a névtér
Visszalépés
Viszont a példa rámutat arra, hogy mennyire kifordított logikával vagyunk kénytelenek gondolkozni, amikor hagyományos, HTML alapú oldalt vagy alkalmazást készítünk.
Először is tisztázni kéne, hogy mire való a HTML: adatok prezentációs leírónyelve (az adatokról később írok). A kulcsszó a "prezentációs", tehát megjelenítésre szolgál, valamint leginkább szöveges információ vizualizálására alkalmas.
Mivel gyorsan elterjedt, elkezdték többféle célra is használni, s csakhamar kiderült, az eredeti elképzelésnek nem felel meg (a HTML), mivel szabványosan nehézkes a HTML-ben megjelenített adatok manipulálása. Jó példa erre a posztban bemutatott <button> elem, amit a Dojo keretrendszer készítői arra használnak, hogy az ízlésüknek megfelelő gombot rajzoljanak a képernyőre, vagy akár a Weblabor forráskódjában található RDF kód, amit jobb híján HTML megjegyzésbe kényszerültek tenni az oldal készítői. Ugyancsak a HTML éra torzszülöttje a pár éve használatos getElementsByClassName() függvény és társai.
Mennyivel egyszerűbb lenne az életünk, ha az adatokat elkülönítenénk a megjelenítéstől - ez a gondolat ismerős lehet sokaknak, jópár éve hasonlóak merültek fel, csak szerveroldalon, MVC programozási modell és társai.
Egy analóg példa arra, hogy a HTML-t miként is használjuk most: úgy kell elképzelni, mintha a weboldalunk szövegeit CSS-ben a :after selector segítségével próbálnánk kiírni a képernyőre. Vagy egy másik: csodálatos piros Ferrarink elromlik, elvisszük a szerelőhöz, aki úgy tudja megszerelni, hogy előbb szétszedi a karosszériát, aminek a belsejébe a mérnökök belevésték, hogy "ha a karburátor elromlik, húzd meg ötször azt a csavart". Nem ott van a helye.
Ideális esetben tehát a böngésző külön kapná meg a feldolgozandó adatokat, amiből a megfelelő logikával elkészítené a HTML kódot. Az adatokat is két részre lehetne bontani: 1, az oldal felépítését leíró strukturális blokkra, 2, a megjelenítendő adatokra.
Amint ez a szétválasztás megtörténik, rögtön könnyebbé válna az adatok gépi feldolgozása (zárójelben jegyzem meg, hogy ez már most is lehetséges, gondoljunk csak a YQL-re). Ennek egy hozadéka, hogy egyszerűbben fel tudnánk vázolni az adatok közti összefüggéseket, és végeredményképp kaphatnánk értelmes válaszokat arra, ha a keresőbe beírjuk: "Hidvégi Gábor hozzászólásai internet témában".
Ez persze a távoli jövő, de egy biztos: ha a HTML-t nem kezeljük a helyén, és továbbra is a web egyik alapvető kommunikációs és adattároló eszköze lesz, a fenti cél eléréséhez szükséges időt nyugodtan szorozzuk meg egy kettőnél nagyobb számmal.
A végére egy jó hír: a mai technológiákkal ez az egész megoldható, méghozzá szabványosan és visszafele kompatibilisen.
Tökéletesen egyetértek azzal,
Az XSLT köszöni szépen, jól
A fejlesztői közösség pedig mi vagyunk, és nem muszáj beállni a nyájba azért, mert ott az a foltos racka hangosabban béget a többinél.
Szerveroldalon biztos
XSLT
Én a következőt állítom: létezik ma az a technológia,
- aminek a segítségével az adatokat szétválaszthatjuk a megjelenítéstől, így megtehetjük az első lépést a szemantikus web felé, azaz előre felé kompatibilis,
- a böngészők nagy része támogatja, tehát kliensoldalon pontosan ugyanazt kapjuk, mint eddig,
- szerveroldalon támogatott, ezért minden kliens, amelyik nem ismeri a technológiát, HTML formában kapja meg az adatokat, ide értve a keresőket is, tehát visszafelé kompatibilis,
- szabványos.
Természetesen nem lennék annyira határozott, ha nem lenne mire alapoznom. Egy most készülő munkámat már ezzel a technológiával készítettem el, a fejlesztés eredményeit és valamint a szükséges forráskódot a közeljövőben szeretném publikálni, valamint nyílt vitára invitálni a kollegákat a témával kapcsolatban.
Hogyan oldod meg, hogy a
A http fejlécek alapján talán
Szerintem fontos, hogy minden
Ez nem feltétlen igaz, json-t
Az egyetlen probléma ezzel az xml+xsl-es témával amibe belefutottam, az ajaxos megoldások. Hogyan oldod meg ugyanazzal az xsl-el ajaxosan és anélkül az oldal generálását?
JSON
Node miért van szükség a JSON-ra, amikor ott van az XML, amit minden böngésző beépítve tud transzformálni? Tehát a JSON technológiailag visszalépés. Lehet, hogy a JSON tömörebb, de ez az előny azonnal elveszik, amint tömörítve küldöd a tartalmat.
"Hogyan oldod meg ugyanazzal az xsl-el ajaxosan és anélkül az oldal generálását?"
Jó a kérdés, viszont a válasz igazából adja magát, ha az ember belemélyed a témába, és jóval egyszerűbb, mint elsőre sejtenénk. A megoldásom, amit hamarosan publikálni fogok, AJAX-ot használ (viszont szinkron módban, mivel az aszinkronitásban - egyelőre - nem hiszek), amikor lehet, és van beépített URL kezelés is, azaz az ilyen módon kiszolgált oldalakat is lehet Kedvencek közé pakolni, meg a böngésző oda-vissza gombjait használni.
Hú hát ez nagyon sejtelmesen
Nekem két megoldás jutott eszembe, az egyik, hogy részekre szedem az xslt-t, és csak az adott résznek megfelelő xml-re húzom rá a sablont, a másik, hogy csinálok egy jó nagy xsl fájlt, amibe mindent beleteszek, és azzal transzformáltatok mindent. Azt hiszem kipróbálom ez utóbbit valamikor, az egyetlen probléma a jogosultság kezelés, mert nem szeretné az ember, hogy olyan dolgok legyenek az xsl-ben, amikről nem szabadna tudnia a felhasználónak.
Én az utóbbit használom, azaz
bár természetesen jobb, ha a
Hát ezzel kapcsolatban arra jutottam, hogy generáltatni kell az xsl fájlokat jogosultság függően. Mondjuk generálok egy hash-t a jogosultságokból, az lesz az xsl fájl neve, és egy ilyen xsl fájlt csak az szedhet le, akinek megegyezik a hash-e az xsl hash-ével. Ez egész jól használható megoldás, csak a jogosultság változásoknál (login,logout) xsl fájlt kell váltani, ami meg azt jelenti, hogy ilyenkor muszáj újratölteni az oldalt. Továbbá ez a megoldás megbonyolítja az xsl fájlok böngészőben történő kesselését. Nyilván a nagy xsl fájlokat érdemes böngészővel kesseltetni....
Ez tipikusan az a kérdéskör, ahol egyik problémából következik a másik, de szerintem megéri foglalkozni vele, ha az ember ajaxos oldalakat akar készíteni, mert senki sem szeret kétszer dolgozni, meg terhelési szempontból is jobb, ha a sablonozás kliens oldalon megy.
(off: szinkron?)
A "szinkron mód" ajaxot úgy érted, hogy megakad a JS futása, amíg nem jön vissza válasz? Ez nem kényelmetlen felhasználói oldalon, ha kicsit tovább tart a válasz megérkezése? Vagy valahogy ezt sikerült kiküszöbölni?
(Azért kérdezem ezt, mert nekem is szimpatikus a szinkron mód, de ezek a gondok miatt mégsem nagyon használom)
Én a szinkron xhr-t nem
XSLT segítségével kevesebb
Egy egyszerűsített példa: az oldal tetején található a felhasználói sáv, ahol bejelentkezés előtt a felhasználói név és jelszó beviteli mező jelenik meg, bejelentkezés után meg a felhasználó neve és egy kijelentkezés gomb. Az ehhez szükséges kódot értelemszerűen csak ki- és bejelentkezés után kell kiküldenem a klienshez.
Igazából a szinkron és aszinkron feldolgozás között pár soros a kódbeli különbség, szóval innentől kezdve a fejlesztő ízlésére van bízva, hogy melyiket választja.
mikro
És ki mondta, hogy
Miért ne lehetne? Viszont
Viszont xslt nélkül kénytelen vagy újraírni az egészet javascriptben, ami miatt redundáns lesz a kódod, és emiatt sokkal több lesz a hibalehetőség.
Tudtam, hogy lépre fog valaki
Erre már én is gondoltam ;-)
Nagyon-nagyon-nagyon nagy jövő van benne ;-) Szerintem eltörölheti a php-t néhány éven belül, aminek kifejezetten örülnék :-)
Az elmúlt hetekben dolgoztam
beleintegrálni
A Node.js nem csak arról
Hát ez borzalmas ötlet :D
jspp
FYI: http://pecl.php.net/pack
http://pecl.php.net/package/v8js
Tyrael
Hoppá!
szemely szerint nem tartom jo
a core reszeve tenni legalabbis.
ha szerver oldalon js-t akarsz hasznalni, lelked rajta, van tobb elerheto implementacio, csomo szituacioban meg jo otlet is lehet.
Tyrael
csak az elterjedés miatt
VPS
Egyik barátom is pont tegnap mondta, hogy valószínűleg a régi tárhelyéről átviszi az ügyfeleit egy másik szolgáltatóhoz VPS-re, mert lassan jobban megéri neki kifizetni a VPS+üzemeltetés árát, mint a hosting miatt szívni (konkrét baja, hogy PHP 5.1 van és még csak nem is tervezik, hogy valamikor frissítenek újabbra.
(úgy értettem)
Mi a probléma a böngészős
A Firefox és/vagy Chrome nem
Hát passz, kíváncsi vagyok mi
XSLT támogatottsága
Annyi kiegészítésem lenne, hogy Firefox igazából az 1.0-ás verzió óta támogatja az XSLT-t teljeskörűen (2004 novemberében jelent meg), ami azt jelenti, hogy már akkor scriptelhető volt.
Most néztem, a 2.0-át máig
XSLT 2
Általában nincs szükség rá,
Az XFORMS is ugyanilyen
A böngészőgyártók szerint
Kösz... :D Azért nekem
Azért nekem kényelmesebb lenne, ha mondjuk soappal tudnék kommunikálni, a szerver oldalon meg servicek lennének, a validálás meg automatikusan menne a wsdl alapján.
Kezdeményezés
Mint az egyik korábbi hozzászólásomban jeleztem, az általam kifejlesztett technológiát szeretném közzétenni a közeljövőben, valamint a közösséget bevonva a problémákat feltárni, azokra választ találni, és végül egy komplett szoftverfejlesztési tervet készíteni, hogy mindenki a legkevesebb erőfeszítéssel felhasználhassa fel.
Első körben, amennyiben van érdeklődő, szeretnék egy Skype konferenciát tartani valamelyik este (mondjuk február 16-án, szerdán este hétkor), ahol bemutatom az oldalt, valamint a forráskódot. Aki részt venne, kérem, jelezzen vissza itt, valamint írja meg a kapcsolatfelvételi lapomon keresztül a Skype azonosítóját.
Amit az általam készített fejlesztés tud:
- az adatokat szétválasztjuk a megjelenítéstől, így megtehetjük az első lépést a szemantikus web felé, azaz előre felé kompatibilis
- a böngészők nagy része támogatja, tehát kliensoldalon pontosan ugyanazt kapjuk, mint eddig,
- szerveroldalon támogatott, ezért minden kliens, amelyik nem ismeri a technológiát, HTML formában kapja meg az adatokat, ide értve a keresőket is, tehát visszafelé kompatibilis,
- szabványos
- amennyiben a kliens támogatja, a kéréseket az XMLHTTPRequest segítségével dolgozzuk fel
- ez utóbbi esetben a szabványos url használat biztosított, azaz minden oldal url-je megmarad, működik, valamint a böngészőkben is használható továbbra is az oda-vissza gomb.
A megbeszélés során
- vázolom a megoldandó problémát,
- bemutatom a működő weboldalt,
- átvesszük a kliens- és szerveroldali fejlesztéseket.