Tiltott fejlesztések (a webappok 10 éves problémája)
Nemrég volt blogmarkolva a W3C Widgets ajánlása. A témával kapcsolatban felmerült a Google Gears is… Úgy tűnik szánt szándékkal kerülgetik azt az egyetlen problémát, ami a webalkalmazások nagykorúságát gátolja, mégpedig a fájlátvitelt. Hatalmas csalódás volt Google Gears-szel kapcsolatban, amikor kipróbáltam a YouTube új multi-feltöltőjét. Letöltöm a Gearst, elindul az applet… az első kérdés: engedélyezed-e a youtube.com-nak a teljes hozzáférést a HD tartalához? Ez volt, amit utáltam a Java appletekben még 10 éve. Ennyire tellett a guglitól?
Ha ma egy webalkalmazásban szeretnéd megnyitni a táblázatodat (a widgetes cikkben PPK ezzel példálózik), nem kell mást tenned, mint feltöltöd a szolgáltatást működtető cég szerverére, aki (némi opcionális feldolgozás után, ami kliensoldalon is elvégezhető lenne) visszaküldi neked. Ezzel két nyilvánvaló probléma is van. Nem szeretnék egy ADSL feltöltési képességeire várni amég megnyitom a fájlomat. Másrészt lehet, hogy én nem vagyok elég "nyitott", de teljesen idegen a gondolat, hogy egy harmadik félnek hozzáférést engedjek minden dokumentumomhoz (ami mellesleg azzal jár, hogy egy náluk előforduló biztonsági probléma az én adataimat is veszélyezteti).
Egy dolog az, hogy a Google szerverein tárolom a dokumentumaimat (bennük valami felfoghatatlan okból megbízunk), de a webalkalmazások kora azt jelentené, hogy egy eddig ismeretlen magyar vagy ukrán vagy kóreai cég webalkalmazását is gond nélkül használhatom, hiszen a modell alapötlete a biztonság.
Visszatérve az alapkérdésre: miért nem lehet a fájlfeltöltéshez hasonlóan egy dialógusablak segtségével egyszerűen bemásolni egy tetszőleges fájlt a buborékba ahol a webapp fut? (Meg persze adott esetben kihozni onnan egy dokumentumot, amire mondjuk a base64-el kódolt URL-ek néhány böngészőben megoldást jelentenek).
Egy másik dolog a webalkalmazásokkal kapcoslatban, hogy a "hazatelefonálást" magától értetődőnek vesszük. Erre abszolút semmi szükség letöltött webappok esetén. Egyetlen legitim oknak a frisstések ellelenőrzését látom, ami könnyedén (és biztonságosan) beépthető lenne a depolyment (ez hogy van magyarul) szabványba, azaz a widgetet vagy webappot futtató hosztalkalmazás garantálhatná hogy semmi olyan információ nem hagyja el gépünket amit mi nem szeretnénk.
■ Ha ma egy webalkalmazásban szeretnéd megnyitni a táblázatodat (a widgetes cikkben PPK ezzel példálózik), nem kell mást tenned, mint feltöltöd a szolgáltatást működtető cég szerverére, aki (némi opcionális feldolgozás után, ami kliensoldalon is elvégezhető lenne) visszaküldi neked. Ezzel két nyilvánvaló probléma is van. Nem szeretnék egy ADSL feltöltési képességeire várni amég megnyitom a fájlomat. Másrészt lehet, hogy én nem vagyok elég "nyitott", de teljesen idegen a gondolat, hogy egy harmadik félnek hozzáférést engedjek minden dokumentumomhoz (ami mellesleg azzal jár, hogy egy náluk előforduló biztonsági probléma az én adataimat is veszélyezteti).
Egy dolog az, hogy a Google szerverein tárolom a dokumentumaimat (bennük valami felfoghatatlan okból megbízunk), de a webalkalmazások kora azt jelentené, hogy egy eddig ismeretlen magyar vagy ukrán vagy kóreai cég webalkalmazását is gond nélkül használhatom, hiszen a modell alapötlete a biztonság.
Visszatérve az alapkérdésre: miért nem lehet a fájlfeltöltéshez hasonlóan egy dialógusablak segtségével egyszerűen bemásolni egy tetszőleges fájlt a buborékba ahol a webapp fut? (Meg persze adott esetben kihozni onnan egy dokumentumot, amire mondjuk a base64-el kódolt URL-ek néhány böngészőben megoldást jelentenek).
Egy másik dolog a webalkalmazásokkal kapcoslatban, hogy a "hazatelefonálást" magától értetődőnek vesszük. Erre abszolút semmi szükség letöltött webappok esetén. Egyetlen legitim oknak a frisstések ellelenőrzését látom, ami könnyedén (és biztonságosan) beépthető lenne a depolyment (ez hogy van magyarul) szabványba, azaz a widgetet vagy webappot futtató hosztalkalmazás garantálhatná hogy semmi olyan információ nem hagyja el gépünket amit mi nem szeretnénk.
kliens oldal
Szerintem ez azért nem megy olyan gyorsan, mert a kliens oldal módosítása kell hozzá, és ehhez még a Microsoftnak sincs lehetősége, nemhogy még valaki harmadik személynek. (Úgy értem, hogy még a MS sem tudja egyszerűen eltüntetni még az IE6-os közönséget sem, szóval szinte reménytelen ilyen nagy változásokat gyorsan és üzletileg hatékonyan eljuttatni az embereknek). Talán részben ezért is próbálkozik a Google a Krómmal: ha nála van a kliens oldali fejlesztés lehetősége, akkor hipphopp megtud csinálni ilyesmit is.
Nem értem
Egyébként nagyjából az lehet a gond, hogy a web máig egy dokumentum alapú közeg. Lehet, hogy végsőkig feszegetjük a korlátokat, és ezt mi webalkalmazás fejlesztésnek hívjuk, ez a platform akkor sem alkalmazások számára lett megalkotva, és egész addig nem is lesz valódi előrelépés, ameddig a szabvány- és technológiaalkotók nem hajlandók ezt belátni.
Szerintem a technológiai
Vázlat
Had vitatkozzak...
Valóban, dokumentum-alapú az architektúra, viszont a dokumentumok leírására használt nyelv (XML) képes bármilyen adatszerkezetet megvalstani. (Egyeseket hatákonyabban, másokat kevésbé).
A DOM segtségével gyakorlatilag bármit módosthatunk a "dokumentumunkban" vagyis az alkalmzásunk UI-jában (vagy határfelületén, ahogy tetszik). Tehát az oldal betöltődésének pillanatában semmi nem dőlt el, semmit nem köt meg a klasszikus értelemben vett dokumentumunk tartalma, viszont nagyon kényelmes módot ad az interfész-elemek kezelésére: a HTML reprezentációt tekinthetjük az UI elemek szerializált változatának is. - Gondoljunk csak arra, amikor egy szerver HTML részletet küld a kliensnek egy XMLHTTP hvásra.
A kliensoldali tárolás problémáját célzó megoldások még gyerekcipőben járnak, viszont a legtöbb program ma is dokumentum-alapú, tehát ha az alkalmzásnak "oda tudunk adni" fájlokat a helyi lemezről az nagy százalékban megoldja a perzisztencia kérdését. Minimális konfogurációt pedig az évtiezedes Cookie szebvány segtségével ma is tárolhatunk.
Vitatkozzunk!
A HTML (megfelelő, széleskörben használt egyéb szabvány hiányában ne beszéljünk általánosságban XML-ről*) egész egyszerűen nem rendelkezik elégséges eszközkészlettel. 20 éve nem tudunk egy szerencsétlen menüt létrehozni HTML-ben. Nem, a számozatlan felsorolás az nem menü. És lehetne folytatni a sort nagyon hosszan.
A DOM pedig egy vicc, jQuery nélkül az ember inkább meg se piszkálja.
Nem tagadom, mostanság elindult az alkalmazások irányába a platform, de ehhez kellett 20 év, aminek a második fele fejlesztői részről az egyre bravúrosabb trükközéssel telt (és akkor még csak az alkalmazásfelületekről beszéltünk, tipográfiáról nem is). És akkor ne beszéljünk arról, hogy egy HTML5 még mindig milyen messze van mondjuk a XUL-tól, és hány év múlva lesznek a most fejlesztésnek indult technológiák valóban elérhetők.
* Amit általában eleve rosszul használnak, nem markup nyelvként, hanem afféle objektum leíró szintaxisként, ami viszont teljesen idegen tőle, és a legkevésbé hatékony. Objektumok leírására ott van pl. a JSON. De az MS web slice-jai is sokkal közelebb állnak egy jelölőnyelv filozófiájához, mint az RSS és Atom…
BOM
A DOM teljesen jó, ami minket idegesít az a Browser Object Model, illetve hogy nem egy browser mind felett :-)
Egyébként szerintem ezt a kérdést nem lehet így elintézni, ha valaki menüket stb. dolgokat akar, használjon delphi-t vagy hasonlót, melyben nyugodtan lehet neten kommunikáló alkalmazásokat írni, valahogy mégsem terjedtek el.
DOM
Nem, én a W3C DOM specifikációról beszélek, ami szerintem (és nem csak szerintem) egészen azt a benyomást kelti, mintha az írói megpróbáltak volna a lehető legkevésbé természetes felületet alkotni, mintegy szórakozásból bosszantandó a fejlesztőket. Kifacsartabb interfészt nehéz lett volna kitalálni (nézd meg vele szemben a már említett jQuery-t, milyen egyszerű és intuitív az összes vonatkozó függvénye).
Éppenhogy így nem lehet elintézni a kérdést. Minden weblap használ menüket, ezek szinte mind megfeleltethetők az asztali alkalmazásokban megszokott menük valamelyik fajtájának, tehát egyértelmű igény volna rá, hogy egyszerű és megfelelő szemantikával rendelkező módja legyen a deklarálásuknak.
menü
Tudom
<ul id="menu">
, ahogy a nav sem lesz több. Attól ezek még a gyakorlatban felsorolások maradnak, egyetlen előnyük, hogy annyit már tudnak majd róla gépek, hogy navigációs célt szolgálnak. Ez még azért messze kevés.megoldás?
Megoldás
De ez ugye nem ugyanaz, mint
Persze, hogy nem
Mellesleg szerintem a DOM egy nagy kalap szar :) És nem, attól sem lesz jobb, hogy én nem csináltam jobbat :)
Tudom, hogy a DOM csak egy
„Leginkább azt, amit menünek szánnak.”
„Épp azért hoztam fel a menüket, mert szerintem ez az a natív UI elem”
Két menüfogalmat keversz.
„ami gyakorlatilag mindenhol jelen van a weben” – a natív menü?? Egyébként ha a XUL szabvány lenne, ez akkor sem lenne igaz, mert a web nagyrészt még mindig dokumentumfunkciót tölt be.
„Én 90%-ban azért használom a jQueryt, hogy ne kelljen a DOM-ot.”
Én 90%-ban azért utazok repülővel, hogy ne kocsival kelljen. Attól az még két külön kategória.
„Egyébként pl. PHP-ban hogy használjak jQueryt?”
Nem értem a kérdést.
„Nem tudok róla, hogy az OOP-ben és a józan gondolkodásban bármiféle sorsdöntő paradigmaváltás következett volna be az elmúlt húsz évben.”
Nem értem, hogy jön ez ide. Egy AFF-ről (alkalmazásfejlesztői felület, API) beszélünk, nem?
„Szerintem a szabványoknak pont olyan ütemben kéne változniuk, ahogy a kiforrott igények megjelennek rájuk.”
Mikor kiforrott egy igény? De ezen felesleges lesz vitatkoznunk. Minden böngészőfejlesztőnek kellene egy részleg, amelyik a jQuery fejlesztőjének ötleteit gyorsan leimplementálja? Aztán ha véletlenül beelőz a prototype, akkor gyorsan átírni az egészet?
És még mindig nem értem, miért bántja a csőröd, hogy ha van egy igényed, erre van egy megoldás, ami egy szinte havi periódusokban frissülő keretrendszer, akkor használod. Miért baj, ha ez nem a szabvány része?
A szabvány soha nem cutting edge megoldás, de a cutting edge megoldások irányt mutatnak a szabványoknak. Mire az újdonságok leszivárognak a szabványba, az idő. Azon keseregni, hogy ez nem 0 = utópia.
És ismétlem, nem szabványnak lenni is előnyös, mert a megoldásod versenyeztetve van.
Nem eszik olyan forrón
Holott nem így van, mindkettőnek vannak részei, amiket súlyosan elhibázottnak látok, egyáltalán nem vagyok fanatikusa egyiknek se. Egyedül azért emlegetem őket, mert általam ismert, a jelenlegi szabványoknál jóval hatékonyabb technológiák – példát kértetek arra, milyen irányban képzelem el a fejlődést, hát adtam.
Mégpedig melyeket?
Miért, szerinted itt fenn a weblabor menüje mit imitál?
Tisztán már semmiképp sem. Te is tudod, hogy már-már nullához tart az olyan webhelyek száma, ahol nincs legalább egy adminisztrációs felület, még ha maga a tartalom dokumentumfunkciójú is. Azonban már ez utóbbira sem elegendő a HTML, épp a napokban beszélgettünk erről a szomszédban a címsorok kapcsán. A HTML-t önálló dokumentumok leírására tervezték, nem online folyóiratok lapjaihoz.
A helyes analógia inkább az „azért veszek saját kocsit, mert nem szeretem, hogy a céges a kormánnyal ellenkező irányban fordul, a plafonról lóg le a sebváltó és ki kell szálljak lecsavarni a benzinsapkát, ha be akarom kapcsolni az ablaktörlőt” lenne.
Nem értem a kérdést.
Én nem csak JavaScriptben akarok XML-t kezelni, hanem PHP-ban, Rubyban, C++-ban ki tudja még hol. A DOM kínszenvedés, mindegyikhez megtalálni (ha létezik), majd kitanulni az elérhető legjobb könyvtárat pedig némileg luxus.
Igen, arról beszélek, hogy a unintuitív és sánta az az API.
Értelmes API-kra mindig is alapos igény volt. Natív UI-t leíró nyelvre? Azért amikor már lassan nem készítesz alkalmazást adott felületi elem nélkül, akkor már jogosan nevezhető kiforrottnak rá az igény, nem? Űrlapmező szűrés és érvényesítés, valaki?
Mert a szabványok arra lettek kitalálva, hogy azokat a dolgokat, amikre mindnyájunknak szüksége van, egységes, interoperábilis formában nyújtsák számunkra. DOM-manipulációra napi szinten van szükséged fejlesztőként, a szabvány nyújt rá egy nyakatekert megoldást, a jQuery, de biztos vagyok benne mindegyik másik népszerű könyvtár, legyen az épp a Prototype, az Ext, vagy bármely másik pedig nyújt rá egy másikat, amit az emberek sokkal inkább hajlamosak használni és tény, hogy mennyivel rövidíti le a fejlesztési időt, teszi átláthatóbbá a kódot stb. Ezek után benned nem merül fel, hogy lehet, hogy a szabvány rossz megoldást kínál?
Teljesen érthető. De könyörgöm, tízévek, miközben olyan marha büszkék vagyunk a fénysebes fejlődésünkre?
„Minden weblap használ
Ebben a kijelentésben mit kell menü alatt érteni? Három linket egymás mellett? A weblaboron van menü? Vagy csak az menü, ami legördül? És hogy kell kinéznie? Szabad stilizálni?
A XUL-t hiányolod a szabványból, a XUL viszont natív UI, és nem hiszem, hogy ilyen értelemben igaz lenne a fenti kijelentés.
Egyébként miért kell mindennek szabványnak lennie? Használd a jQueryt, mi ezzel a gond? A jQueryt (meg a társait) nem lehet a DOM-mal szembeállítani, hiszen az egy ráépülő absztrakciós réteg, sajátos látásmóddal, és örvendetes módon egy piaci verseny részese. És persze van a kettő közt 20 év. A szabványok nem változnak ilyen gyorsan, és nem is lenne jó, ha ilyen gyorsan változnának. Ez egy egészséges rétegződés.
Nagyjából mind
Leginkább azt, amit menünek szánnak. Pillanatnyilag a lapszámozáson (ami megint olyan visszatérő struktúra, ami megérne egy saját elemet) kívül nem jut eszembe semmilyen jelenleg navigációs célból bevetten alkalmazott módszer, amire ne mondhatnánk, hogy menü. A Weblaboron egyértelműen van menü fenn, talán oldalt is. Nem csak a legördülők számítanak menünek, elvégre asztali környezetben is igen változatosak lehetnek. Szabad stilizálni, elvégre asztali környezetben is stilizáljuk. A lényege az lenne, hogy dedikált elemet használnánk, ami bír a neki szánt jelentéssel, az alapértelmezett megjelenés és viselkedés pedig felesleges munkától kímélne meg minket.
Épp azért hoztam fel a menüket, mert szerintem ez az a natív UI elem, ami gyakorlatilag mindenhol jelen van a weben, de vehetjük az űrlapokat vagy még ezer más dolgot, és aztán ha eljutottunk a webalkalmazásokhoz, ott végképp megvolna rá az igény.
Én 90%-ban azért használom a jQueryt, hogy ne kelljen a DOM-ot. Kétlem, hogy egyedül volnék, már csak azért is, mert akkor meg sem írták volna a traversal és manipulation függvényeket. Márpedig ez azt jelenti, hogy ilyen felületet kellett volna alkotni a szabványosítás során. Egyébként pl. PHP-ban hogy használjak jQueryt?
Nem tudok róla, hogy az OOP-ben és a józan gondolkodásban bármiféle sorsdöntő paradigmaváltás következett volna be az elmúlt húsz évben.
Ezt a kijelentést nem látom igazán alátámasztottnak. Szerintem a szabványoknak pont olyan ütemben kéne változniuk, ahogy a kiforrott igények megjelennek rájuk. Sajnos ennél a valóságban jóval lassabban szoktak.
Menü, stb
A DOMról meg úgy gondolom, hogy semmiben nem köti meg a kezed. Mint ahogy meg lehett írni egy jQueryt DOM alapokon mást is meg lehet. Ha te kiterjedt manipulációkat folytatsz a DOM fával akkor természetesen célszerűbb egy erre optimalizált, neked kézreálló eszközt használnod.
Ha rossz szabványt akarsz látni, akkor nézz bele a Microsoft-féle MFC-be.
Szemantika, alapértelmezett viselkedés
Mennyiért vállalsz nekem egy webappot csak
span
-ekben? Lenne benne jó sok űrlap. De aztán jó legyen ám a helyezésem a Gugliban! ;)Miért? Tényleg nem tűnik logikusnak egy levelezőt, táblázatkezelőt, adminfelületet, akármit olyan elemekből felépíteni, amik ilyen felületekhez lettek kitalálva?
Egyetlen Turing-teljes programnyelv sem köti meg a kezed, mégsem érdemes weblapot fejleszteni Brainfuckban.
Hé, érveljünk etikusan! :D
Webapp vs weblap
Amúgy (a form elmektől eltekintve) simán flépthető (persze szabványos böngészőkben) SPAN elemkből egy UI. Úgy sem fogsz soha hozzáférni ezekhez az elemekhez direktben. Az alkalmazáslogika és az UI kapcsolata valami YUI-szerű rétegen keresztül fog történni. Ezen a ponton nem számt a HTML reprezentáció (a HTML-t csak a szerializált változatnak tekinthetjük, aminek tartalma, olvashatósága hótmindegy).
A Brainfucknál nemhinném, hogy a felhasználóbarátság volt az elsődleges :D , ahogy a gépi kódnál sem. Ez nem akadályoz meg, hogy a gépi kód fölé magasabb rétegeket pl JS interpreter éptís a saját kedvedre.
Lényegtelen
Ezzel csak a „minek az?” felkiáltásod meggondolatlan voltára próbáltam rávilágítani – szemantikai oldalról. Menüt pl. nem csak az alkalmazások használnak.
Ezzel csak a „minek az?” felkiáltásod meggondolatlan voltára próbáltam rávilágítani – alapértelmezett funkcionalitás oldaláról.
Mit értesz direkt alatt? A (tudom-tudom, már megint) XUL direkt?
Ezzel nem értek egyet teljesen. A mindent JS-ből és spanból építünk fel pedig épp a legfőbb előnyét veszi el az egésznek renszernek: a szabványos, tehát jelentést hordozó eszközkészletet.
Mert bár a dokumentumok leírása terén is rengeteg igény lenne új elemek bevezetésére, az alkalmazások terén sincs ez másként. Most ne beszéljünk arról, mennyivel macerásabb neked is JS-ből összerakni egy datepickert, de én, ha még egy pár évig bámulom a képernyőt és tényleg magvakulok, akkor nem foglak szeretni, hogy egy spankupacot tolsz az arcomba.
És igen, tudom, hogy pillanatnyilag a Google-t jelentő gépi feldolgozás messze nem célcsoportja egy webalkalmazásnak, de ez nem lesz mindig így. Legalábbis, ha megérjük, ugye 50 év múlva fizetünk a másiknak egy sört, ha igaza lett? ;)
A kérdés az, hogy ilyenkor én Brainfuckban fogom-e lekódolni a C-t, vagy mégis inkább Assemblyben?
Értem...
A "direktet" arra értettem, hogy adott esetben egy DateTimePicker mint JS objektum lesz látható az alkalmazáslogikád felé, és az ő metódusait hvogatod majd, nem pedig a dom-ban álltgatod majd a pickert feléptő SPAN elemeket. - Ahogy ma egy LightBox is működik.
Azt viszont teljesen megértem, hogymiért ragaszkodsz a szemantikához. Ez egy webapp számára olyan lehetőséget (muszáj lenne ismét a "réteg" szót használnom, de már túl sokszor előttem) jelent, ami más, desktop fejlesztőeszköz esetén nem létezik. Egy delphis program UI-jából vajmi keveset tudunk meg ha az ablak információit egy másik programból dolgozzuk fel (némi egymásbaágyazástól eltekintve).
Egy felolvasóprogram számára rengeteg információt hordozhat az alkalmazás egy képernyője ha a mögötte álló szemantika is elérhető (pl melyik input mező melyik formhoz tartozik). Erre viszont ma is meglenne a lehetőség.
Egyrészt az XHTML kibővíthető tetszőleges tag-ekkel. Másrészt egy kevésbé forradalmi megoldás: mikroformátumok. Mennyi energiát követelne egy "Audible Apllications" mikroformátum-szabvány kidolgozása? - Hmm... ezen érdemes lenne komolyan gondolkodni.
lehet én vagyok a hülye de az
phpQuery
http://code.google.com/p/phpquery/
Köszi
XML meg objektumok?
Inkább nevezzük hierarchikus adatszerkezeteknek azokat az objektumokat. Egyébként szvsz az xml erre a feladatra ugyanúgy alkalmas mint a JSON.
Nem arra termett
Meglátásom szerint pedig az XML nem egy jó választás, ha a feladat hierarchikus adatszerkezetek leírása. Egyrészt nagyon terjengős, másrészt pedig tényleg nem erre lett kitalálva: mi szükség hierarchikus adatszerkezetek esetén az XML attribútumaira? Amikor az ember maga állít össze egy XML formátumot efféle célra, akkor szinte azonnal beleütközik a dilemmába, hogy attribútum vagy gyermek ág. Ennek oka, hogy az SGML egy leírónyelv volt, ahogy talán az XML is annak indult, ott pedig a címke nyitó és záró párja közt a megjelenített szöveg áll, míg a címke maga és attribútumai adnak a szövegdarabhoz metainformációt. Maga a terjengőssége, a címke zárásakor a címke nevének megismétlése is csak a még átlapolható címkéket használó SGML-ből ered, és egyedül ott volt haszna.
Régen nagyon lelkes voltam az XML kapcsán, ma már elhibázottnak tartom: két szék között a földre esett szegény, jelölőnyelvnek már nem az igazi, objektum-leírónyelvnek még nem.
hierarchikus
Ezzel együtt egész sok célra, egész jól sikerült XML-eket kitalálni, ez szintén nem azt mutatja, hogy annyira elhibázott lenne. Vannak feladatok, ahol simán elég egy egyszerű JSON, ott lehet azt használni, senki sem kényszerít. De az XML egy jóval erősebb eszköz ettől függetlenül, és van ahol meg ez jön jól. Pontosan meg tudod határozni egy adott XML struktúráját, és ezt szabványos, nyelvfüggetlen módon tudod validálni, míg JSON esetén kb. azt tudnád csinál, hogy minden fajta JSON esetére írsz minden egyes nyelven egy kis értelmezőt.
Offszet
Mióta átlapolhatók az összetevői.
Nyilván, nem azt mondom, hogy használhatatlan, csak azt, hogy az esetek többségében olyasmire használják, amire nem ő lenne az optimális megoldás (pl. konfigurációs fájlok).
De hát ugyanez érvényes az XML-re: minden egyes nyelvre írtak hozzá egy értelmezőt. Ugyanígy lehetne egy szabványos struktúra megadási módot kidolgozni JSON-hoz, YAML-höz, inihez, akármihez. Ez az érv legfeljebb annyiban jártszik, hogy XML-hez már most rendelkezésre áll ilyen, íg yha tényleg szükséged van egy efféle keresztplatformos ellenőrzési lehetőségre, akkor jó választás lehet, de szerintem ez az esetek kisebb százaléka.
Önmagában a sok lehetőség nem pozitívum. Szerintem ha hierarchikus adatokat tárulonk, akkor inkáb dilemma forrása az attrubútumok léte, mint logikusan kihasználható lehetőség. Nekem legalábbis ez volt a tapasztalatom.
De akkor el is vész az átfedések lehetősége.
„az esetek többségében
Ez lenne az esetek többsége?
Azt hiszem
eszközök/szerkesztő
xml
Attribútum vs. gyerek elem
Igazából nagyon egyszerű, mikor mit érdemes használni. Ha egy adott entitásnak a tulajdonságait akarod leírni, az attribútum, ha a tartalmát — ez lehet CDATA-tól kezdve kisebb entitás —, akkor pedig gyerek elemet helyezel bele.
...és meg is született a hierarhikus adattárolás :)
Amíg az XML-ben tudsz konkrétan egy elemre hivatkozni (XPath), addig a JSON objektumodban nem, mivel nincs (feltétlen) "azonosítója" az adott értékeknek
ennyire nem egyszerű azért ;)
észrevételek
Meddig menjünk el, mik legyenek ezek az alap elemek? A legtöbb weboldal számára nincs szükség ilyesmikre, max az adminban, de még ezekben is elég gyakran nincs szükség egy ExtJS bonyolultságra, illetve RIA-ra van elég sok egyéb lehetőség is, nem muszáj a HTML-t erőltetni.
Picit off
Némiképp erőltetetten, de lehet struktúrát bevinni ld. pl. http://jsonml.org
ebben sincs struktúra
Elfogadom amit mondasz
Válaszok
Érdemes lenne esetleg ebből kikerekíteni egy bejegyzést/cikket, de most csak gyorsan: Flickr, YouTube, Digg, MySpace, Facebook, Last.fm mind tipikus horizontális menüt használnak, a legtöbb lenyílót. A koncepció ugyanaz, csak máshogy vannak kicsicsázva. Egy direkt erre a célra szánt elemet pedig egyértelműen könyebb beállítani, már-már szégyellem, hogy megint a XUL-t hozom fel, de hát ha már ott a kész példa…
Itt tényleg az dönt, mire van igény. Persze igény alatt nem azt kell érteni, hogy mit kérnek az emberek, ugyanis az emberek a legtöbbször nem is tudják, mire van szükségük (mielőtt felháborodsz, gondolj az átlag megrendelőre :)), azonban a gyakorlat (weboldalak milliói) mutatják, hogy pl. egy ilyen elem megérdemelné az önállóságot. Ez ugye épp nem is olyasmi, ami csak adminra kéne. És van még rengeteg jó dolog az asztali alkalmazásokban, amire bizony nagy igény volna weben is (nincs most erőm utánagondolni, de most pl. eszembe jutnak fülek, amik még hasonló joggal pályázhatnának).
Az egyéb RIA pedig legfeljebb fejlesztői szempontból jobb (kényelmesebb), de szemantikailag még rosszabb (pl. Flash), mint a jelenlegi HTML-ből barkácsolt szerkezetek. Arról nem is beszélve, mennyivel kisebb a támogatottságuk, mint annak a HTML-nek, amitől a web web lesz.
Biztos nincs egyszerű dolguk, de azért webfejlesztői körökben már-már közhelyes a munkatempójuk. Sőt, igazából nem is azzal van a baj, hogy lassan dolgoznak, inkább azzal, hogy rendszeresen nem csinálnak semmit hosszú évekig (lásd HTML).
Lehet, hogy erre tervezték a W3C-nél, ez esetben viszont azt mondom, hogy rossz volt a koncepció. Lásd a hozzászólásom eggyel feljebb, amiben ki is fejtem. A struktúrainformáció alatt mit értesz pontosan? Szerintem ugyanúgy lehet hozzá írni egy szabályrendszert és ellenőrizni egy JSON (PHP, Python, Ruby, C++, akármilyen) objektum hierarchiát, mint az XML-t.
Jó-jó, de azért a józan észt nem az elmúlt 13 évben publikálták, jól mondom? Azért egy láncolhatóságot, meg hogy ne kelljen már az objektumot paraméterként átadnom önmaga függvényének (most írtam valamit, nem tudom pontosan min szívtam a fogam, mikor legutóbb DOM-manipuláltam, de a felállás ilyen), az elvárható lenne, ha már ugye objektumorientált API-t tervezünk.
Remove/replace DOM element
Nekem ilyen az, amikor a DOM-ból egy elemet kell eltávolítani:
design
:?
Őőő ... Tehát a dokumentumodhoz nem adnál hozzáférést egy harmadik félnek, de egy komplett alkalmazásnak a komplett gépedhez igen???
Sztem ezt gondold újra ...
Nem erre gondolt pontosan
(Ehhez hasonló most is megtehető, ha pl. egy textarea-ba beleillesztesz egy excel táblát, a webapp feldolgozza, majd visszaadja az eredményt szövegként.)
Félreértessz...
Az az érdekes, hogy olyan platformok, mint a Flash vagy a Gears gondnélkül újíthatnának ebben a tekintetben, hiszen nem a biztonsági modell lazításáról van szó, hanem egy jelenleg használt ügyetlen gyakorlat lerövidítéséről.
Fura például, hogy ugyanezt a gyakorlatot követi a flash is a FireReference objektumnál. Egy "open" dialógusablak után elérhetővé teszi a kiválasztott fájl méretét, dátumát, mime típusát, a tartalmába viszont nem enged betekinteni. Az upload metódussal persze feltölthetjük a fájlt a szerverre (amivel ezután azt csinálunk amit akarunk).
Kiegésztés: Gears
Ez mind szép és jó. Egyetlen probléma a dologban, hogy a Blob nem redelkezik toString vagy getBytes (vagy semmilyen más hasonló) metódussal, így szkriptünkből lehetetlen hozzáférni az adatokhoz. Az adattartalmat csakis a Gears függvényei érik el.
Egyelőre elég kevés függvényt tartalmaz az API, nem tartom kizártnak, hogy a jövőben lesz majd egy hack-megoldás, egy függvény, aminek átadva a Blobot valami módon (monjuk egy Exception részeként) visszakapjuk az eredeti tartalmat. Mindenképpen érdekes azonban, ahogy a sok bába között elsikkad a gyerek a Gears berkeiben is... :)
Eddig jutottam én is
Lehet, hogy rosszul emlékszem, de mint ha lett volna ilyen "hiányzó láncszem" megvalósítás Silverlightban, talán a Flickr-en, aminek a lényege az lett volna, hogy még feltöltés előtt tudtál manipulációkat végezni kliensoldalon a képeken.
Re: Nem eszik olyan forrón
A natívat és a stilizáltat.
„Miért, szerinted itt fenn a weblabor menüje mit imitál?”
Nyilatkozz már légy szíves, hogy a weblabor menüje helyén szívesebben látnál egy natív menüt, vagy sem. És itt lent a láblécben is vannak horizontálisan elrendezett linkek, azt is menübe kéne rakni, nem? Az is imitált menü, nem? Natívba, igaz?
Abból, hogy egy vizuális koncepciót, amit menünek is lehet hívni (meg még sokminden másnak), a weblapok használnak, még nem következik, hogy ezeknek mind natívnak kellene lenniük. Erre semmilyen igény nincs.
„Én nem csak JavaScriptben akarok XML-t kezelni, hanem PHP-ban, Rubyban, C++-ban ki tudja még hol. A DOM kínszenvedés, mindegyikhez megtalálni (ha létezik), majd kitanulni az elérhető legjobb könyvtárat pedig némileg luxus.”
Most itt már nem tudom, mivel van baj, a DOM-mal, az XML-lel vagy a Rubyval... (És pláne hogy oldja meg ezt az általam föl nem fogott problémát a jQuery...)
„Ezek után benned nem merül fel, hogy lehet, hogy a szabvány rossz megoldást kínál?”
Nem. A szabványt nem minősíti az, hogy egy ráépülő keretrendszert használok.
„De könyörgöm, tízévek, miközben olyan marha büszkék vagyunk a fénysebes fejlődésünkre?”
A fénysebes fejlődés fontos előfeltétele, hogy a felbukkanó új megoldások versenyeznek. Te a jQueryt egy év után szabványosítanád, majdnem ennyi ideig vezetett előtte a prototype. Komolytalan a gondolat.
Értelmezz, ne forgass ki
Egy natív menüt miért ne lehetne stilizálni? Ha én telepítek egy egyéni témát Firefoxra, akkor onnantól már nem számít natívnak a menüje? Szerintem csak teljesen mást értünk ebben az esetben natívon.
Jó, hagyjuk ezt a natívat. A weblabor fejléce alatt egy klasszikus menüsáv van, az oldal látványvilágához igazított stílussal. Pont.
Nem, abban nem vagyok biztos, hogy pontosan mi, de egy biztos: nem hivatkozások, márpedig a HTML-ben csak hivatkozások vannak.
Hagyjuk a natív kifejezést, a menü egy vizuális-funkcionális, asztali alkalmazásokból eredő koncepció. Egyértelműen ezt imitáljuk a Weblabor fő navigációjához hasonló elemekkel, így jogosnak tűnik az igény, hogy egy dedikált struktúrával jelölhessük, ahelyett, hogy a legkülönfélébb, jelentésben igen távol eső darabokból rakjuk őket össze.
Vagy elég jó magyarból ahhoz, hogy az ezek szerint barokkosan cizellált gondolatmenetem megfejtsd, ha akarod. Szerintem mondjuk elég világosan írtam. Inkább érzem úgy, hogy vita helyett finoman lejáratni próbálod a partnered, hathatósan megtámogatva némi goebbelsi retorikával.
Kivéve ha a keretrendszert nem plusz funkcionalitás, hanem a szabvány kiváltására használom.
Argumentum ad nausam, ismét.
Hagyhatjuk a natív
A weblapokon szigorú értelemben véve nem menük vannak, hanem arra többé-kevésbé hajazó navigációs megoldások, de ezt te is leírtad, mikor ilyen szavakat használtál, hogy "imitál" stb. De ezzel mi a gond? Nem is akar többet, él a maga világában.
Vagy szerinted akar? Fenntartom a kérdésem a weblaborral kapcsolatban. Mi a gond azzal? Csak annyi, hogy UL helyett MENU tag kellene?
„márpedig a HTML-ben csak hivatkozások vannak.” – meg lista, meg blokk.
„jogosnak tűnik az igény, hogy egy dedikált struktúrával jelölhessük, ahelyett, hogy a legkülönfélébb, jelentésben igen távol eső darabokból rakjuk őket össze.”
Ha azon vitatkoznánk, hogy mennyivel szebb lenne a NAV az UL helyett, hát jó, de hogy erre a XUL mint alternatíva... Egy weblabor menüre!... A XUL nem arra van kitalálva, hogy stilizáld.
„megfejtsd, ha akarod” – Egyáltalán nem értem, hogy a DOM-jQuery témától hogy jutottunk el a rubys XML-feldolgozásig.
„Kivéve ha a keretrendszert nem plusz funkcionalitás, hanem a szabvány kiváltására használom.”
Ez egy jó észrevétel, de azért sok dolog van a másik oldalon. És semmi konkrét javaslatot nem tudok belőle levezetni. Szerintem senkinek nem lenne jó, ha most hirtelen jQuerys api-ja lenne a DOM-nak. Nekem, jQuery-rajongónak sem.
„Argumentum ad nausam, ismét.”
Nem tudom, miért mondod ezt, nem is reagáltál rá. Az, hogy ezek a keretrendszerek versenyeznek, az fontos.
menüzuldomdzséjkverirubikszemel
Ez tényleg így van, de ez annak az eredménye, hogy mivel a kívánt technika nem állt rendelkezésre, így nagy szabadságunk volt, hogyan használjuk rosszul a meglévőt. Aztán ez ma már természetesnek hat. Félre ne érts, nem akarom én egyenruhába bújtatni a webet, de ilyen alapon minek a HTML5 bármelyik újdonsága? Elvégre valahogy eddig is meg tudtuk oldani azokat a dolgokat.
És azért nagyon sok asztali alkalmazás bír egyéni designnal (leginkább ugye Windows környezetben), miközben a klasszikus interfész elemek továbbra is jól felismerhetőek.
Én továbbra is fenntartom, hogy a fejlécekben elhelyezett horizontális, gyakran lenyíló linksáv nem különbözik egy asztali alkalmazásokban megszokott, stilizált menütől. De az oldalsávokon elhelyezett vertikális menüknek is itt vannak a kiköpött másai az állománykezelőmben. Természetes, nem minden navigációs elem lesz beskatulyázható egy ilyen menübe, de ez így van bármelyik HTML elemmel: az igényelt dokumentumszerkezet nagy része lefedhető a rendelkezésre álló címkékkel, de minden projektnél van egy-egy olyan szöglet, ahol az ember gondolkodóba esik, mit is gépeljen köré. Az imitál szót azért írtam, mert listákat pofozunk át a felismerhetetlenségig, hogy olyasmit kapjunk, mint amit itt látunk a böngésző tetején is.
Az, hogy az ott fenn nem egy felsorolás, köze sincs hozzá. Az egy menü. Tökéletesen idegen szemantikailag (habár a rendelkezésre álló teljesen másra rendeltetett eszközkészletből még a legpraktikusabb választás ilyen célra, tagadhatatlan), és egy csomó munka van vele. Míg egy dedikált menu tag esetén egyik oldalról lenne egy navigációs elemed, amit felismer a böngésző, a felolvasó, a kereső; másikról pedig CSS és JS trükközés nélkül, a markup bepötyögése után lenne egy működőképes menüd.
Ezt honnan veszed? Akkor hogy-hogy mégis létezik egy kisebb óceánnyi Firefox téma? Nyilván nem arra való, hogy megerőszakold, ahogy azt pl. a felsorolásokkal tesszük, de egyetlen elem sem arra hivatott, hogy a hagyományos jelentésköréből teljesen kiforgassák.
Pedig csak annyi, hogy a DOM-ot, lévén szabvány, nagyjából mindenhol megvalósítják, majdhogynem ugyanúgy. jQuery viszont csak JavaScriptben van. Ha én Ruby-ban, Pythonban, CPP-ben akárhol máshol akarok egy hatékony XML API-t, akkor kezdődhet a keresgélés, és jobb esetben a tanulás. Ezért lenne fontos egy jól használható szabvány.
Ismét hangsúlyozom: itt egyáltalán nem a jQuery a lényeg, hanem egy hatékony API. A jQuerynek éppenséggel az van (kifejezetten a traversal és manipulation tagfüggvényeire gondolok, még csak nem is a CSS kiválasztó rendszerére), valószínűleg más könyvtárak is csináltak maguknak egyet. És én nem is verem az asztalt, hogy cseréljük a DOM-ot jQueryre, még csak azért sem, hogy most azonnal cseréljük le valamire, csak megjegyeztem, hogy annak idején a tisztelt alkotói is rendelkezhettek volna annyi józan paraszti ésszel, mint Resig úr, elvégre nem olyasmi az a felület, aminek a kialakításához diploma kéne…
Arra vonatkozott, hogy hiába beszélek én, mégis hajtogatod, hogy én szabványosítani akarom a jQueryt (sic). Pedig ugye nem. A verseny jó.
"csak hivatkozás"
Nem hivatkozás, nem lista
A vízszintesen egymás mellé igazított elemek pedig nem alkotnak listát abban az értelemben, ahogy a HTML definiálja azt.
????
Hivatkozások, gombok, listák
Egy jelölőnyelv esetén csak hivatkozásról beszélhetünk: adott szövegdarabot kiegészíthetünk egy kapcsolódó, ezen aktust követően mondhatni hivatkozott erőforrás címével. Amikor nem a meglévő szöveghez adunk hozzá, hanem magunk helyezünk el egy navigációs elemet, az egy teljesen más kategória.
A felolvasó szofter általában jó szemléltető eszköz: ha a pillanatnyilag rendelkezésre álló horgonyt használjuk a menühöz, műveletek kiváltásához, akkor elvileg annak elejétől végéig végig kellene olvasnia a teljes szöveget, valamiféle enyhe akusztikus jelzéssel élve ott, ahol hivatkozás van. Márpedig mndnyájan ismerjük, milyen problémás még listaként jelölt menük esetén is az egész felolvasósdi, hát még ha ez sincs. Ezzel szemben egy dedikált menü elem, dedikált gomb elemek esetén ezzel nem volna gond.
Csak űrlapokhoz. Én a klasszikus anchort viselkedést hiányolom, épp csak egy alkalmazásokban használatos gomb szemantikájával.
Amellett, hogy teljesen nyilvánvaló, bizony a szöveges leírás is elég egyértelmű utalásokat tartalmaz. Ha egy lista pusztán egyenrangú vagy rendezett elemek egymásutánisága lenne, akkor a folyószöveget is jelölhetnéd mondatok, szavak és betűk egymásba ágyazott, majd CSS-sel fomázott struktúrájává.
egyértelmű utalás
Adatvédelmi problémákat vet fel
És hogy a DOM-os vitába is beleröfögjek. Egy webalkalmazásban szvsz totál lényegtelen, hogy milyen szemantikus elemekből épül fel a UI. Elsőként is azért, mert JS-es, pláne AJAX-os/AJAJ-os, SJAX-os/SJAJ-os alkalmazásban a kulcsfontosságú tartalmak user action nélkül nem érhetőek el, tehát keresőmotor szempontjából felesleges is vizsgálni a kérdést, és akkor is felesleges lenne, ha a keresők amúgy értelmezni (futtatni, emulálni) tudnák a JS-t. Másrészt azért, mert a user tojik rá hogy a csilivili (vagy fapadder) UI-t hogyan hekkeltük az ő monitorába bele. Egyszerűen egy webalkalmazás a külvilág felé zárt, általában egy darab login ablak és maximum néhány reklám/termékinfó releváns a külvilágnak, a belépett felhasználónak pedig az egyedi tartalom a releváns, amit viszont ő értelmez, többnyire mélyreható informatikai ismeretek nélkül, egyszerű ránézésre (akit ha nagyon el akarunk kápráztatni, akkor használunk például ExtJS-t, ami elé varázsol egy hejjre pofás kis desktop alkalmazás feelinget és nem mellékesen fejlesztési oldalon is vastagon növelheti a hatékonyságot).
Off(?) Miért teszünk ki valamit a webre?
Ha visszamegyünk egy picit a kályhához, vajon miért teszünk ki valamit a webre? Az én piciny világomban ez leegyszerűsödik két dologra:
1; valamit el akarunk mondani, reklámozni, vitatni, mutatni, mesélni, valamilyen módon eszmét cserélni, információt közölni, akármi, melynek módja a szöveg. Nem a videó, nem a kép, nem vagyok egy marketingszakember, de a reklámok mindegyike nem hiába zár szöveges résszel, mert ez az ami megragad, és ez az amivel valamit el tudunk mondani igazán. Tehát text, a http és a html második t-je.
2;. Platformfüggetlenek szeretnénk lenni. Józsi bácsi szeretné hogy ha a linuxos kisfiánál Kukutyimban, a MACes amerikai nagybácsinál, és a jó öreg windows akárhányon is meg tudja nézni a leveleit, vagy dokumentumait, vagy alkalmazás generátorral alkalmazást tudjon generálni. Persze igaz, hogy erre böngészőjét kell használni, melyet tényleg nem erre találtak ki, de még mindig jobb (szerintem még nekünk fejlesztőknek is!) mintha egy javas alkalmazást kellene adatbázisostól, mindenestől felhúzni az említett OS-ek alatt, és utána patch-elgetni, vigyázva, hogy minden úgy működjön ahogy annak kell.
A menü elemet is sokszor emlegetitek. Nézzünk egy egyszerű példát, szeretnék egy bejelentkező oldalt, de nem akarok túl sok infóval elárasztani a látogatót, annyit akarok hogy választhasson "cicák" meg "kutyák" között. Nyilván nem követek el nagy hibát, ha azt mondom, hogy ez legyen két <h2> elemben, hisz az oldal szempontjából szemantikailag fontos infó, legyen továbbá két <a> elemben, hisz ez link lesz másik oldalra, de nem hiszem hogy fontos lenne ul-be rakni, (bár nem lehetetlen) és így azt sem hiszem hogy ha lenne egy <menu> elem, akkor abba beleraknám.
Szóval a specializáltság itt szerintem hátrányunkra válna.
Tehát a lényeg:
Alkalmazás
Miért jó az, hogy mindent beleerőszakolunk a HTTP/HTML/JS/stb.-vel összegányolt egyvelegbe és közben egyre több olyan igényt támasztunk felé, ami a desktop alkalmazásoknál már rég megoldott feladat.
Munkatársakkal is egyre többször beszéljük, hogy az admin felületeket nem HTML+JS-ben kellene lekódolni, hanem megírni - teszem azt - egy C#-s desktop programban. Ahelyett, hogy szívatjuk magunkat és a megrendelőnek is egy egyre inkább nehézkesen kezelhető felületet próbálunk használhatóvá alakítani, fel lehetne használni a fejlesztési időt értelmesebb dolgokra.
Mindenki tudja a HTTP-ről, és a felette lévő protkolokról, hogy nem arra használjuk, amire kellene. Nem kellene tovább erőltetni. RFC 3252 is jó vicc volt, de ne akarjuk már alkalmazni a gyakorlatban is ;)
jézus
Ceriak: csinálj XML-ben menüt, tedd ki saját XSLT-vel a lapod, és kész, a vita el van intézve.
Az eredetihez: a kutya ott lehet elásva, hogy az eredeti megközelítésen kellene módosítani. Szerintem a megoldást egy új protokoll jelentené, mint a DAV volt anno.
Nem teológia
Egyáltalán nem tértünk el, továbbra is alkalmazások kontra webről van szó.
A vitát nem elintézni akarjuk, hanem lefolytatni – gondolom a többiek is azért vesznek részt benne, mert érdekli őket a másik véleménye, és elmondanák a sajátjukat. A vita jó dolog.
eredeti...
Már említettem, hogy magukhoz a webalkalmazásokhoz szerintem egy teljesen új protokollra és megközelítésre lenne szükség - persze, hatalmas munka, de valószínűleg megérné, kérdés, kinek.
(Akkor lehetnének saját szabványai, amikkel neked is megfelelő alkalmazásokat lehetne készíteni.)
Más kérdés, hogy szerintem erősen különbséget kellene tenni webalkalmazás és hálózati alkalmazás között.
A webalkalmazás számomra azt jelenti, hogy alapvetően egy weboldalról beszélünk, ami ilyen-olyan lehetőségekkel ki van egészítve, amiről viszont a cikk szól, azt inkább fedné valami olyan, hogy hálózati alkalmazás.
Személyes meglátás: azért, mert neked valami nem tetszik, nem szabad leszólni. A FORTRAN pl. mai szemmel nézve elég meredek nyelv, mégis a mai napig fejlesztik, és meg is van az oka (ld. MATLAB).
Szóval csak óvatosan a kinyilatkoztatásaiddal a DOMról, az XMLről és a hasonló dolgokról, mert elég okos emberek találták ki őket, valószínűleg okkal úgy, ahogy vannak.