ugrás a tartalomhoz

HTML5-re tér át a Dojo

Török Gábor · 2011. Feb. 11. (P), 07.52

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.

 
1

Visszalépés?

saxus · 2011. Feb. 11. (P), 20.43
Ugyan nem Dojozok, de ebből csak annyit látok, hogy ami rövidebb volt eddig, az most hosszabb lett, de semmivel sem jobb megoldás, mint az előző.
2

Visszalépés

Joó Ádám · 2011. Feb. 11. (P), 20.56
Esetleg adhatnánk nekik hexadecimális sorszámot, úgy még gyorsabban be lehetne gépelni őket.
3

Szabvány

Török Gábor · 2011. Feb. 11. (P), 21.10
Lehet, hogy nem sikerült artikulálnom, de mindez arról szólna, hogy ez eddigi markupodat, amire még a HTML validátor is sikoltott, mostantól megírhatod szabványos jelölések segítségével.

(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 a dojoType-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.)
22

Validator

saxus · 2011. Feb. 13. (V), 05.38
"amire még a HTML validátor is sikoltott"

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.
25

Mármint mi nem visszafele

Joó Ádám · 2011. Feb. 13. (V), 12.11
Mármint mi nem visszafele kompatibilis?
36

Picit félreérthetően fejeztem ki magam

saxus · 2011. Feb. 13. (V), 18.15
A visszafelé kompatibilitást úgy értem, hogy nem lehet a már meglévő kódokat átvenni. Ez alatt nem csak a meglévő XHTML->HTML5 váltást értem (igen, el lehet vitatkozni, hogy most az XHTML nem tekinthető közvetlen ősének a HTML5-nek, de gyakorlatilag erről kell váltani).

É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.
37

Érdekes az attribute-os

inf3rno · 2011. Feb. 13. (V), 18.41
Érdekes az attribute-os linked, nem értem, hogy hogyan lehet egy map-et dataset-nek elnevezni.....
40

Úgy, mint a PHP

saxus · 2011. Feb. 13. (V), 18.49
Ahogy a PHP is a hashmapjeit is tömböknek hívja. ;)

Gondolom amiatt, hogy plusz adatokat lehet így egy elementhez hozzárendelni, emiatt adathazlmaz.
41

Tudtommal az XHTML-ről való

Joó Ádám · 2011. Feb. 13. (V), 19.24
Tudtommal az XHTML-ről való átállás nagyjából a doctype elhagyását és a névtér átírását jelenti. Ezen túl hol nem visszafele kompatibilis a HTML5?
53

"átírását"

saxus · 2011. Feb. 18. (P), 10.37
Az nem visszafelé kompatibilitás.
54

A doctype és a névtér

Joó Ádám · 2011. Feb. 19. (Szo), 21.56
A doctype és a névtér metaadat, gyakorlatilag verziószám. Ha nem írod át, akkor nem HTML5-öt szolgálsz ki, hanem XHTML-t, de akkor meg miért beszélsz visszafele kompatibilitásról? A böngésződ mindkettőt meg fogja jeleníteni.
4

Visszalépés

Hidvégi Gábor · 2011. Feb. 11. (P), 22.44
Én is sokat gondolkoztam, hogy milyen előnnyel járhat a data- attribútumok bevezetése, s az jött ki, hogy mivel belekerülnek a HTML elem datas nevű tömbjébe, talán picivel könnyebb végigiterálni rajtuk.

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.
5

Tökéletesen egyetértek azzal,

Joó Ádám · 2011. Feb. 11. (P), 23.30
Tökéletesen egyetértek azzal, amit mondasz. Ezt hívták XSLT-nek. A fejlesztői közösség leszavazta.
6

Az XSLT köszöni szépen, jól

Hidvégi Gábor · 2011. Feb. 12. (Szo), 00.20
Az XSLT köszöni szépen, jól van, él és virul. Elterjedésének egyetlen komolyabb oka van: a keresők nem támogatják (minden más igen). Viszont szerencsére létezik áthidaló megoldás.

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.
7

Szerveroldalon biztos

Joó Ádám · 2011. Feb. 12. (Szo), 00.27
Szerveroldalon biztos kiválóan működik, én balga módon próbálkoztam vele a múltkor böngészőben, kár volt. Egyébiránt pedig amíg a kereső nem foglalkozik vele, addig bizony nem él és virul, hanem döglött.
8

XSLT

Hidvégi Gábor · 2011. Feb. 12. (Szo), 12.37
A próbálkozás kevés, csak az eredmény számít.

É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.
13

Hogyan oldod meg, hogy a

Joó Ádám · 2011. Feb. 12. (Szo), 17.08
Hogyan oldod meg, hogy a kereső HTML-t kapjon?
15

A http fejlécek alapján talán

inf3rno · 2011. Feb. 12. (Szo), 19.31
A http fejlécek alapján talán ki lehet választani a botokat... A html adása meg annyi, hogy szerver oldalon csinálod meg a transzformációt. Nem is muszáj ugyanazzal az xsl fájllal, elég csak egy egyszerűbbel, ami kevesebb erőforrást igényel.
18

Szerintem fontos, hogy minden

Hidvégi Gábor · 2011. Feb. 12. (Szo), 23.29
Szerintem fontos, hogy minden transzformáció ugyanazzal az XSL fájllal készüljön, hisz akkor egyrészt nem kell kétszer dolgozni, másrészt mindig ugyanazt a HTML kódot kapjuk meg. Ráadásul, ha folytatjuk ezt a gondolatmenetet, könnyen beláthatja bárki, hogy miért is fölöslegesek és károsak az olyan adatformátumok, mint pl. a JSON. A JSON egyik célja, hogy kényelmesebben lehessen programozni, ami addig igaz is, amíg HTML-t nem kell generálni belőle bármilyen módon, mert akkor kliens oldalon is le kell programoznunk a megjelenítési logikát.
21

Ez nem feltétlen igaz, json-t

inf3rno · 2011. Feb. 13. (V), 00.26
Ez nem feltétlen igaz, json-t xml-re lehet alakítani, amit már lehet transzformálni. json azért jó, mert tömörebb, mint az xml.

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?
23

JSON

Hidvégi Gábor · 2011. Feb. 13. (V), 08.25
"Ez nem feltétlen igaz, json-t xml-re lehet alakítani, amit már lehet transzformálni. json azért jó, mert tömörebb, mint az xml."

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.
26

Hú hát ez nagyon sejtelmesen

inf3rno · 2011. Feb. 13. (V), 12.54
Hú hát ez nagyon sejtelmesen hangzik :D

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.
30

Én az utóbbit használom, azaz

Hidvégi Gábor · 2011. Feb. 13. (V), 13.41
Én az utóbbit használom, azaz egy nagy XSL fájlt, mert így egyszerűbb. A jogosultsági problémáktól kevésbé félek, mert azokat ígyis-úgyis a szerveroldalon kell lekezelni - bár természetesen jobb, ha a támadók nem tudják, milyen paraméterekkel kell azokat a szerveroldali fájlokat meghívni, amelyek a felhasználóspecifikus változtatásokat végzik.
32

bár természetesen jobb, ha a

inf3rno · 2011. Feb. 13. (V), 13.54
bár természetesen jobb, ha a támadók nem tudják, milyen paraméterekkel kell azokat a szerveroldali fájlokat meghívni, amelyek a felhasználóspecifikus változtatásokat végzik.


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.
28

(off: szinkron?)

zzrek · 2011. Feb. 13. (V), 13.34
Lehet egy off kérdésem?
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)
29

Én a szinkron xhr-t nem

inf3rno · 2011. Feb. 13. (V), 13.40
Én a szinkron xhr-t nem tartom szerencsésnek.
31

XSLT segítségével kevesebb

Hidvégi Gábor · 2011. Feb. 13. (V), 13.52
XSLT segítségével kevesebb adatot kell kiküldeni a kliensnek, ezért elvileg kevésbé akad meg a feldolgozás, mint amikor teljes HTML oldalról van szó. És nem csak azért kevesebb a kiküldött adatmennyiség, mert a "sallang", azaz a teljes HTML kód nem megy ki, hanem azért is, mert ha úgy készítem el az alkalmazásom, akkor csak bizonyos részeit kell frissítenem.

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.
33

mikro

zzrek · 2011. Feb. 13. (V), 14.09
Nyilván, én is csak ilyen "mikrotranzakció" esetén vagyok bátor használni néha, köszi a választ.
19

És ki mondta, hogy

Joó Ádám · 2011. Feb. 13. (V), 00.22
És ki mondta, hogy kliensoldalon nem lehet ugyanazt a megjelenítési logikát használni, mint szerveroldalon?
27

Miért ne lehetne? Viszont

inf3rno · 2011. Feb. 13. (V), 12.58
Miért ne lehetne?
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.
34

Tudtam, hogy lépre fog valaki

Joó Ádám · 2011. Feb. 13. (V), 16.43
Tudtam, hogy lépre fog valaki menni. Ha szerveroldalon is JavaScriptben fut, akkor nem kell újraírnom ;)
39

Erre már én is gondoltam ;-)

inf3rno · 2011. Feb. 13. (V), 18.49
Erre már én is gondoltam ;-) Vannak ilyen terveim a node.js-el ;-)
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 :-)
42

Az elmúlt hetekben dolgoztam

Joó Ádám · 2011. Feb. 13. (V), 19.26
Az elmúlt hetekben dolgoztam ilyesmin. Annak ellenére, hogy Bártházi András a budapest.js-en azt mondta, ilyet senki sem akar csinálni…
43

beleintegrálni

zzrek · 2011. Feb. 13. (V), 19.32
(off) Arra gondoltam, hogy meg kéne kérni a PHPseket, hogy integrálják bele a következő php verzióba a node.js-t, mondjuk a <?js ... ?> jelölők közti részt az kezelhetné. Így gyorsan elterjedhetne a hostokon, és párhuzamosan lehetne használni a phpvel ;-)
44

A Node.js nem csak arról

Joó Ádám · 2011. Feb. 13. (V), 19.55
A Node.js nem csak arról szól, hogy JavaScriptet hajtasz végre, egy teljesen más architektúra az egész :)
45

Hát ez borzalmas ötlet :D

inf3rno · 2011. Feb. 13. (V), 20.31
Hát ez borzalmas ötlet :D
46

jspp

Poetro · 2011. Feb. 13. (V), 22.33
Vagy át kell képezni őket, hogy használjanak jspp-t, amiben az alkalmazások írása nagyban hasonlít a PHP alkalmazások írásához, csak JavaScript-ben.
47

FYI: http://pecl.php.net/pack

Tyrael · 2011. Feb. 13. (V), 22.40
bar nem node, de js:
http://pecl.php.net/package/v8js

Tyrael
48

Hoppá!

zzrek · 2011. Feb. 14. (H), 01.18
Nincs új a nap alatt, köszi. Érdekes lenne, ha alapcsomag lenne belőle, új lökést adna a PHPnek. (már amivé alakulhatna ezáltal)
49

szemely szerint nem tartom jo

Tyrael · 2011. Feb. 14. (H), 01.47
szemely szerint nem tartom jo otletnek.
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
50

csak az elterjedés miatt

zzrek · 2011. Feb. 14. (H), 09.56
Csak a JS elterjedése miatt tetszene. Kevés helyen hostolnak JSt, szóval hiába használnék, nincs nagy választék. Nyilván egyébként sokkal jobb a külön implementáció. A PHP sikerének kulcsa (számomra legalábbis mindenképp) hogy bárhol elérhető minimum a hostolásban.
52

VPS

saxus · 2011. Feb. 18. (P), 10.36
Szerintem nem érdemes ragaszkodni minden áron a tárhely hostingokhoz.

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.
51

(úgy értettem)

zzrek · 2011. Feb. 14. (H), 10.05
(Úgy értettem, hogy "amivé alakulhatna", hogy paradigmát válthatna: a PHP nem egy nyelv lehetne, hanem tetszőleges szimpatikus nyelveket felkarolhatna. Ha ezt a paradigmát core részévé tennék, a PHP átalakulhatna, kihasználhatná az előnyét, hogy minden hoston ott van. Ezzel megnőne az életciklusa. Én örülnék neki ha a következő verzióváltáskor azt tapasztalnám, hogy "hopp", az összes eddigi hoston már JS-ben is programozhatok szerver oldalon (nem feltétlen <?js ?> formában, akárhogy, itt most nem ez a lényeg). De ez persze csak egy képzelgés volt, nem gondoltam át komolyan, hogy mivel járna stb, nem akarom tovább szétoffolni a topicot, bocs)
9

Mi a probléma a böngészős

inf3rno · 2011. Feb. 12. (Szo), 16.18
Mi a probléma a böngészős XSLT-vel? Gyakorlatilag minden támogatja... Láttam már komoly látogatottságú oldalt, ami használja.
11

A Firefox és/vagy Chrome nem

Joó Ádám · 2011. Feb. 12. (Szo), 17.05
A Firefox és/vagy Chrome nem implementált valamit. Nem emlékszem a részletekre.
14

Hát passz, kíváncsi vagyok mi

inf3rno · 2011. Feb. 12. (Szo), 19.28
Hát passz, kíváncsi vagyok mi lehet az, mert nekem eddig nem volt vele semmi gondom. Mondjuk még nem használtam élesben, csak próbálgattam, hogy miket tudok csinálni vele, és ilyen crossbrowser dolgok sosem jöttek elő vele kapcsolatban.
17

XSLT támogatottsága

Hidvégi Gábor · 2011. Feb. 12. (Szo), 23.17
http://www.w3schools.com/XSL/xsl_browsers.asp

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.
20

Most néztem, a 2.0-át máig

Joó Ádám · 2011. Feb. 13. (V), 00.25
Most néztem, a 2.0-át máig nem támogatja.
24

XSLT 2

Hidvégi Gábor · 2011. Feb. 13. (V), 08.33
Én eddig minden problémát meg tudtam oldani 1.0-ában is. Valamint hozzá kell tennem, hogy természetesen kevésbé rugalmas nyelv az XSLT, mint például a PHP, és bizonyos helyzetekben más logikával kell gondolkozni, de még így is többet nyerünk vele - főleg hosszú távon -, mint amennyi befektetésbe kerül megtanulni.
38

Általában nincs szükség rá,

inf3rno · 2011. Feb. 13. (V), 18.44
Általában nincs szükség rá, vagy ha mégis lenne, akkor sokszor át lehet hidalni valamilyen saját függvénnyel a problémát. Nekem sem volt még olyan, hogy valamit nem tudtam 1.0-val megoldani...
10

Az XFORMS is ugyanilyen

inf3rno · 2011. Feb. 12. (Szo), 16.19
Az XFORMS is ugyanilyen kezdeményezés volt, sajnos az sem terjedt el valami rohamosan... Én őszintén szólva nem értem, hogy miért, szerintem mindkettő nagyon jó dolog.
12

A böngészőgyártók szerint

Joó Ádám · 2011. Feb. 12. (Szo), 17.06
A böngészőgyártók szerint neked erre nincs szükséged. Elégedj meg a HTML5 űrlapjaival.
16

Kösz... :D Azért nekem

inf3rno · 2011. Feb. 12. (Szo), 19.33
Kösz... :D
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.
35

Kezdeményezés

Hidvégi Gábor · 2011. Feb. 13. (V), 17.52
Tisztelt kollegák!

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.