ugrás a tartalomhoz

Tiltott fejlesztések (a webappok 10 éves problémája)

vbence · 2009. Május. 6. (Sze), 11.04
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.
 
1

kliens oldal

zzrek · 2009. Május. 6. (Sze), 21.25
Egyetértek.
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.
2

Nem értem

Joó Ádám · 2009. Május. 7. (Cs), 00.49
Én már csak azt nem értem, hogy ezt miért nem blogbejegyzésként küldted be? ;)

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

Szerintem a technológiai

Fraki · 2009. Május. 7. (Cs), 02.41
Szerintem a technológiai kriticizmusra fokozottan érvényes az, hogy alternatíva felvázolása nélkül csak üres lózung.
6

Vázlat

Joó Ádám · 2009. Május. 7. (Cs), 19.24
XUL.
8

Had vitatkozzak...

vbence · 2009. Május. 10. (V), 10.42
Szerintem a platform jó irányba halad, sőt nagyrészt már ott is van. Eltekintve a bejegyzésben tárgyalt kényelmetlenségektől a web kielégít minden, alkalmazások számára támasztható elvárást.

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

Vitatkozzunk!

Joó Ádám · 2009. Május. 10. (V), 19.31
Nos, szerintem pedig kínszenvedés (habár számunkra már megszokott) valódi alkalmazást fejleszteni a weben, éppen azért, mert egy teljesen más célból tervezett architektúrára erőltetjük rá.

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…
11

BOM

Ustak · 2009. Május. 10. (V), 22.08
A DOM pedig egy vicc, jQuery nélkül az ember inkább meg se piszkálja.

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

DOM

Joó Ádám · 2009. Május. 10. (V), 22.38
A DOM teljesen jó, ami minket idegesít az a Browser Object Model, illetve hogy nem egy browser mind felett :-)


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

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.


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

menü

gex · 2009. Május. 10. (V), 23.31
volt menü, aztán érvénytelenítették. nem baj, mert jön a navigáció, kérdés hogy a html6-ot megéri-e. :)
14

Tudom

Joó Ádám · 2009. Május. 10. (V), 23.54
Tudom, de ez sem volt több, mint egy szabványosított <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.
15

megoldás?

gex · 2009. Május. 11. (H), 00.34
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.
Tudom, de ez sem volt több, mint egy szabványosított <ul id="menu">, ahogy a nav sem lesz több. Attól ezek még a gyakorlatban felsorolások maradnak [...] Ez még azért messze kevés.
és mit szeretnél? a html ennyire képes.
16

Megoldás

Joó Ádám · 2009. Május. 11. (H), 01.36
Azt szeretném, ha vagy a HTML részeként, vagy különálló, de szabványosított és minden böngészőben használható XML nyelvként meg lenne valósítva egy efféle alkalmazás-felület leírónyelv.
18

De ez ugye nem ugyanaz, mint

Fraki · 2009. Május. 11. (H), 01.47
De ez ugye nem ugyanaz, mint ha azt mondanád, hogy a DOM egy nagy kalap szar. (alkalmazásfelület-leírónyelv)
20

Persze, hogy nem

Joó Ádám · 2009. Május. 11. (H), 03.56
Persze, hogy nem ugyanaz, ugyanis nem is a DOM-ról beszélek (az csak egy elharapózott mellékszál), hanem egy XUL-hoz hasonló UI nyelvről.
Mellesleg szerintem a DOM egy nagy kalap szar :) És nem, attól sem lesz jobb, hogy én nem csináltam jobbat :)
23

Tudom, hogy a DOM csak egy

Fraki · 2009. Május. 11. (H), 11.28
Tudom, hogy a DOM csak egy példa. Én úgy látom, hogy annak okán, hogy a XUL neked tetszik (meg a jQuery), minden mást leszarozol.

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

Nem eszik olyan forrón

Joó Ádám · 2009. Május. 11. (H), 12.06
Én úgy látom, hogy annak okán, hogy a XUL neked tetszik (meg a jQuery), minden mást leszarozol.


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.

Két menüfogalmat keversz.


Mégpedig melyeket?

„ami gyakorlatilag mindenhol jelen van a weben” – a natív menü??


Miért, szerinted itt fenn a weblabor menüje mit imitál?

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.


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.

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


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.

„Egyébként pl. PHP-ban hogy használjak jQueryt?”

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.

Nem értem, hogy jön ez ide. Egy AFF-ről (alkalmazásfejlesztői felület, API) beszélünk, nem?


Igen, arról beszélek, hogy a unintuitív és sánta az az API.

Mikor kiforrott egy igény?


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

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


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?

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.


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

„Minden weblap használ

Fraki · 2009. Május. 11. (H), 01.43
„Minden weblap használ menüket”

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

Nagyjából mind

Joó Ádám · 2009. Május. 11. (H), 03.50
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?


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.

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.


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

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


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

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


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.

A szabványok nem változnak ilyen gyorsan, és nem is lenne jó, ha ilyen gyorsan változnának.


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

Menü, stb

vbence · 2009. Május. 11. (H), 09.30
Nem tudom mit változtatna a dolgon, hogy egy menüt az alkalmazásodon belül milyen elemkkel hozol össze. Persze, a natív menünek is van pár előnye look-and-feel szempontjából, de a webalkalmazásoknál nem cél a natív UI emulálása, mint például egy desktop JAVA appnál. - Egy menüt feismer a user.

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

Szemantika, alapértelmezett viselkedés

Joó Ádám · 2009. Május. 11. (H), 10.34
Nem tudom mit változtatna a dolgon, hogy egy menüt az alkalmazásodon belül milyen elemkkel hozol össze … Egy menüt feismer a user.


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! ;)

de a webalkalmazásoknál nem cél a natív UI emulálása


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?

A DOMról meg úgy gondolom, hogy semmiben nem köti meg a kezed.


Egyetlen Turing-teljes programnyelv sem köti meg a kezed, mégsem érdemes weblapot fejleszteni Brainfuckban.

Ha rossz szabványt akarsz látni, akkor nézz bele a Microsoft-féle MFC-be


Hé, érveljünk etikusan! :D
25

Webapp vs weblap

vbence · 2009. Május. 11. (H), 12.09
Egy webalkalmazásnál nem különösebb szempont a Gugli henyezés.. különösen, hogy a tartalmat általában JS fogja generálni.

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

Lényegtelen

Joó Ádám · 2009. Május. 11. (H), 12.35
Egy webalkalmazásnál nem különösebb szempont a Gugli henyezés

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.

Amúgy (a form elmektől eltekintve) simán flépthető (persze szabványos böngészőkben) SPAN elemkből egy UI.

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.

Ú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

Mit értesz direkt alatt? A (tudom-tudom, már megint) XUL direkt?

Ezen a ponton nem számít a HTML reprezentáció (a HTML-t csak a szerializált változatnak tekinthetjük, aminek tartalma, olvashatósága hótmindegy).

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? ;)

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.

A kérdés az, hogy ilyenkor én Brainfuckban fogom-e lekódolni a C-t, vagy mégis inkább Assemblyben?
27

Értem...

vbence · 2009. Május. 11. (H), 13.11
Neked fontos a HTML reprezentáció, nekem nem. Ebben nemhiszem, hogy közeledni fognak az álláspontjaink.

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

lehet én vagyok a hülye de az

Crystal · 2009. Május. 11. (H), 23.19
lehet én vagyok a hülye de az MFC mióta szabvány? Az egy API, nem?
46

phpQuery

attlad · 2009. Május. 15. (P), 18.53
Egyébként pl. PHP-ban hogy használjak jQueryt?

http://code.google.com/p/phpquery/
47

Köszi

Joó Ádám · 2009. Május. 18. (H), 01.09
Tulajdonképp az lett volna a meglepő, ha nincs ilyen. Köszi, kipróbálom majd.
38

XML meg objektumok?

Crystal · 2009. Május. 11. (H), 23.26
"Objektumok leírására ott van pl. a JSON."

Inkább nevezzük hierarchikus adatszerkezeteknek azokat az objektumokat. Egyébként szvsz az xml erre a feladatra ugyanúgy alkalmas mint a JSON.
48

Nem arra termett

Joó Ádám · 2009. Május. 18. (H), 01.14
Igaz, szabatosabb megfogalmazás, bár szerintem mindenki érti, miről van szó.

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

hierarchikus

Hodicska Gergely · 2009. Május. 19. (K), 11.18
Meglátásom szerint pedig az XML nem egy jó választás, ha a feladat hierarchikus adatszerkezetek leírása. Nem erre lett kitalálva...
Azt halkan kérdezem meg, hogy egy dokumentum az mióta nem hierarchikus adatszerkezet?

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.

mi szükség hierarchikus adatszerkezetek esetén az XML attribútumaira
Ez egy eszköz, ami adott esetben hasznos tud lenni. Vannak alapelvek, amik alapján el lehet dönteni, hogy éppen gyerek elemet vagy attribútumot érdemesebb használni. Programozás során is van amikor egy célt több úton lehet elérni, döntés kérdése, hogy melyiket választod.

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.
Ez tévedés, SGML-ben is van lehetőség rövidített megadási formára.
54

Offszet

Joó Ádám · 2009. Május. 19. (K), 12.39
Azt halkan kérdezem meg, hogy egy dokumentum az mióta nem hierarchikus adatszerkezet?

Mióta átlapolhatók az összetevői.

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.

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

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.

Ez egy eszköz, ami adott esetben hasznos tud lenni. Vannak alapelvek, amik alapján el lehet dönteni, hogy éppen gyerek elemet vagy attribútumot érdemesebb használni. Programozás során is van amikor egy célt több úton lehet elérni, döntés kérdése, hogy melyiket választod.

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

Ez tévedés, SGML-ben is van lehetőség rövidített megadási formára.

De akkor el is vész az átfedések lehetősége.
56

„az esetek többségében

Fraki · 2009. Május. 19. (K), 15.42
„az esetek többségében olyasmire használják, amire nem ő lenne az optimális megoldás (pl. konfigurációs fájlok)”

Ez lenne az esetek többsége?
61

Azt hiszem

Joó Ádám · 2009. Május. 19. (K), 23.38
Nekem ez a benyomásom. A legtöbb XML nyelv (vagyük ide az ad hoc, sehol nem szabványosított „nyelveket” is, pl. a konfig állományokat) olyasmi, amihez simán nem XML kéne. Pl. a kánonból a kedvencem az SVG…
62

eszközök/szerkesztő

Hodicska Gergely · 2009. Május. 20. (Sze), 00.00
Az SVG pedig tényleg tipikusan az, amire még te is írtad, hogy az XML ki lett találva. Amúgy ilyesmikre tipikusan azért szeretik a markupot, mert utána nagyon egyszerű szerkesztőt nyújtani, illetve adott esetben egy sima XML szerkesztő a DTD/schema alapján is elég lehet. Az meg nem mindegy, hogy ha kitalálsz valamit, akkor utána mennyi időbe kerül, hogy eszközöket is tudj nyújtani hozzá.
58

xml

Hodicska Gergely · 2009. Május. 19. (K), 17.56
Mióta átlapolhatók az összetevői.
Ez alatt mit értesz?

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).
Erre Fraki reagált, szvsz. lehet, hogy te ilyen irányból találkoztál XML-lel (ezt special én sem szeretem, de még mindig jobb, mint amikor ini fájlokba van beletrükközve struktúra, yaml pl. tök jó erre).

De hát ugyanez érvényes az XML-re:
Nem egészen, elég nagy a különbség. Mert XML-hez egyszer megírtak egy értelmezőt, validátor, és innentől kezdve minden XML alkalmazásra ez működik, és ezek az eszközök általában a legtöbb nyelv esetén adottak. JSON esetén minden egyes konkrét struktúrára kell írnod egy validátort, nem hiszem el, hogy nem látod a különbséget.

Ö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.
Ez nem öncélű lehetőség, vannak olyan adatok, amik nem igazán önálló entitások, ezek esetén egyszerűbb attribútumot használni, ha ezt egyéb peremfeltételek nem zárják ki.
53

Attribútum vs. gyerek elem

Adam · 2009. Május. 19. (K), 12.36
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.

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
59

ennyire nem egyszerű azért ;)

Hodicska Gergely · 2009. Május. 19. (K), 19.55
Csak két példa: mi van akkor, ha ez egy olyan tulajdonság, ami több elemet tartalmaz? Vagy pl. mi van akkor ha a tulajdonságban fontosak a whitespace-ek? És lehetnek még más hasonló peremfeltételek, amik árnyalják a képet.
34

észrevételek

Hodicska Gergely · 2009. Május. 11. (H), 22.41
Az alap témához: arra azét kíváncsi lennék, hogy nézd meg mondjuk az 500 legnagyobb weboldal menüjét (már amelyiknek van persze), és definiálj egy olyan elemet, amivel ezek könnyen megvalósíthatóak. Szvsz valami elég bonyolult dolog fog kijönni, amiből kb. pont annyi meló lesz kihozni a konkrét menüt (rengeteg apró beállítással szórakozva), mint amennyi most elkészíteni. Ok, persze lehet tudni egyből, hogy ez egy menü, kérdés, hogy ez igazából milyen pluszt ad hozzá a dologhoz.

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.

A DOM pedig egy vicc, jQuery nélkül az ember inkább meg se piszkálja.
Mindig lehet magasabb absztrakciós réteget kitalálni, illetve folyamatosan fejlődnek a dolgok (w3c-nél persze kicsit lassabban, bár elég sok érdeket kell tető alá hozniuk, ami biztosan nem könnyű feladata, és egy elkpakodott szabvánnyal nem lennénk előrébb, arról beszélve, hogy erre elég sok minden épül, így utólag nem túl egyszerű megváltoztatni).

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.
Végülis csak pont ez az XML egyik fő feladata. :) JSON sok mindenre hasznos, de objektumok leírására pont nem, hisz nem hordoz semmilyen struktúrára vonatkozó információt, és ezzel együtt nem is tudod validálni a benne lévő adatot.

Nem tudok róla, hogy az OOP-ben ... bármiféle sorsdöntő paradigmaváltás következett volna be az elmúlt húsz évben.
Hát akkor nem igazán követed az eseményeket. ;) Akár vegyük csak a tervezési mintákat (magyarul!), 13 éve született meg a GoF könyv, ami elég alaposan megváltoztatta a dolgokat. De egy rakás szintén alapvető befolyással bíró mű ennél jóval fiatalabb, pl. Martin Fowler klasszikusok, vagy pl. TDD, MDA, DDD, extrém programozás, és még lehetne sorolni.
41

Picit off

yaanno · 2009. Május. 13. (Sze), 13.49
JSON sok mindenre hasznos, de objektumok leírására pont nem, hisz nem hordoz semmilyen struktúrára vonatkozó információt

Némiképp erőltetetten, de lehet struktúrát bevinni ld. pl. http://jsonml.org
43

ebben sincs struktúra

Hodicska Gergely · 2009. Május. 14. (Cs), 10.54
Ebben sincs struktúra, mert magának a jsonml-nek a struktúráját nem tartalmazza, míg az XML az adat mellett tartalmazza a struktúrát is.
45

Elfogadom amit mondasz

yaanno · 2009. Május. 15. (P), 10.33
Csak annyit tennék hozzá (jó messzire vezet ez a témakör), hogy ez jórészt szintaktikai kérdés. Meg hát másra való a JSON és az XML (fenntartva, hogy az utóbbi kifejezőereje lényegesen gazdagabb).
49

Válaszok

Joó Ádám · 2009. Május. 18. (H), 01.50
Az alap témához: arra azét kíváncsi lennék, hogy nézd meg mondjuk az 500 legnagyobb weboldal menüjét (már amelyiknek van persze), és definiálj egy olyan elemet, amivel ezek könnyen megvalósíthatóak. Szvsz valami elég bonyolult dolog fog kijönni, amiből kb. pont annyi meló lesz kihozni a konkrét menüt (rengeteg apró beállítással szórakozva), mint amennyi most elkészíteni.

É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…

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.

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.

Mindig lehet magasabb absztrakciós réteget kitalálni, illetve folyamatosan fejlődnek a dolgok (w3c-nél persze kicsit lassabban, bár elég sok érdeket kell tető alá hozniuk, ami biztosan nem könnyű feladata, és egy elkpakodott szabvánnyal nem lennénk előrébb, arról beszélve, hogy erre elég sok minden épül, így utólag nem túl egyszerű megváltoztatni).

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

Végülis csak pont ez az XML egyik fő feladata. :) JSON sok mindenre hasznos, de objektumok leírására pont nem, hisz nem hordoz semmilyen struktúrára vonatkozó információt, és ezzel együtt nem is tudod validálni a benne lévő adatot.

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.

Hát akkor nem igazán követed az eseményeket. ;) Akár vegyük csak a tervezési mintákat (magyarul!), 13 éve született meg a GoF könyv, ami elég alaposan megváltoztatta a dolgokat. De egy rakás szintén alapvető befolyással bíró mű ennél jóval fiatalabb, pl. Martin Fowler klasszikusok, vagy pl. TDD, MDA, DDD, extrém programozás, és még lehetne sorolni.

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

Remove/replace DOM element

Adam · 2009. Május. 19. (K), 08.58
Azért egy láncolhatóságot, meg hogy ne kelljen már az objektumot paraméterként átadnom önmaga függvényének...

Nekem ilyen az, amikor a DOM-ból egy elemet kell eltávolítani:
element.parentNode.removeChild(element);
vagy amikor lecserélni egy másikra:
element.parentNode.replaceChild(newElement, element);
A többihez, ami fentebb olvasható meg akartam reagálni, de úgy érzem megint erőből megy a vita, illetőleg egymás mellett elbeszélés van.
60

design

Hodicska Gergely · 2009. Május. 19. (K), 21.18
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…
Persze, csak a nyereség valszeg minimális lesz, hisz ugyanúgy el kell tökölnöd a kinézettel (szvsz ez viszi el a legtöbb időt egy menű esetén), valamint azt szintén nem tudod megúszni, hogy megadd, hogy mi történjen, ha kiválasztasz egy adott menüpontot. Ergo ott vagy, hogy kb. más a markup, amire "ráhúzod" ezeket. Szemantiakailag lehet előrébb lennénk, de nem is erre reagáltam.

Lehet, hogy erre tervezték a W3C-nél, ez esetben viszont azt mondom, hogy rossz volt a koncepció.
Miért érzed rossznak a koncepciót? Abból, hogy nem egyértelmű számodra, hogy atribútum vagy gyerek elem, vagy hogy kell egy lezáró szöveg, szerintem elég erős azt mondani, hogy koncepcionálisan rossz. Szvsz abszolút webfejlesztő szemmel nézed az XML-t, és ebből vonsz le egy általános következtetést, ami nem biztos, hogy szerencsés. Webhez egyértelműen közelebb áll a JSON, de inkább gyakorlati okokból, például cross domain kérések esetén a JSONP elég hasznos, illetve könnyebb egy JSON válasszal dolgozni JavaScriptben (de pl. ha E4X elterjedne, akkor ez már nem állna fel). Olvastam pl. régebben egy érdekes cikket, ahol azt taglalták, hogy a JSON egyszerűsége az XML-hez képest egyből nem olyan egyértelmű, amikor komplexebb adatstruktúrákról van szó.

Jó-jó, de azért a józan észt nem az elmúlt 13 évben publikálták, jól mondom?
Nem, de nem is erre reagáltam. De a józan ész is amúgy relatív némileg, ezer olyan új ötlet keletkezik folyamatosan, amikre azt lehetne mondani, hogy nem is értem, hogy miért nem elsőre így lett kitalálva, annyira logikus. Ez egy ilyen játék.

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.
Amit itt megint figyelmen kívül hagysz, az a teljes kép. A DOM tervezésekor egy csomó olyan dolognak kellett megfelelni, amik korlátozták a használható eszközöket. A legkülönbözőbb fajta nyelvekkel is tudnia kell működnie, ezek mind eltérő tulajdonságokkal rendelkezenk, ezért az API gyakran elég erős kompromisszumokat kellett elszenvedjen. Sajnos ennek a linkjét se találom már, de olvastam valahol egy interjút ezzel kapcsolatban, ott több konkrét példa is fel volt sorolva, hogy ez vagy az azért lett így kitalálva, mert C-ben vagy C++-ban ez vagy az nincs, JavaScriptben meg emez nincs. Ezzel együtt lehetnek benne fölösleges vagy fölöslegesnek tűnő elbonyolítások, de erre azt mondani, hogy józan ész hiánya az megint csak elég bátor kijelentés, szvsz elég komoly szakemberek dolgoztak ezen, rágódtak rajta elég sokat.
4

:?

fchris82 · 2009. Május. 7. (Cs), 09.44
Tehát neked az az elképzelésed, hogy felcsatlakozol a netre, beírsz egy URL-t, betöltődik egy program, ami teljesen hozzáfér a HD-hez és a gép minden egyéb erőforrásához, és te úgy tudod használni, mint egy telepített programot? Vagy mi? És az az egyik érved, hogy:
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

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

Nem erre gondolt pontosan

zzrek · 2009. Május. 7. (Cs), 09.55
Azt hiszem nem pont erre gondolt, hanem arra, hogy felesleges egy fájlt felküldeni a szerverre, ott feldolgoztatni és aztán leszedni, amikor már eleve a kliensnek is átadható lenne. Vagyis nem a kliensszoftver kutakodna a háttértárban, hanem ugyanazt a műveletet végeznéd el, mint most a fájlfeltöltéskor, csak épp nem töltenél fel semmit, hanem a fájl adatait tennéd elérhetővé a javascript számára.
(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.)
7

Félreértessz...

vbence · 2009. Május. 7. (Cs), 21.09
...a teljes hozzáférés kérését tartom a legrosszabb megoldásnak. (A második bekezdésben ezt le is írom).

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

Kiegésztés: Gears

vbence · 2009. Május. 10. (V), 11.04
A Gears file-megnyitásában nagyon érdekes, hogy a dokumentáció szerint elérhetővé teszi számunkra a fájl tartalmát.

var callback = function (files) {
	alert("length: " + files[0].length);
	alert("content: " + files[0].blob);
}

var desktop = google.gears.factory.create("beta.desktop");
desktop.openFiles(callback, {singleFile:false});
És valóban, meg is kapjuk a fájl tartalmát reprezentáló Blob objektumot. A Blob szabványt a Google bináris adat tárolására dolgozta ki - a JS String tipusa nem lenne gazdaságos erre.

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... :)
42

Eddig jutottam én is

yaanno · 2009. Május. 13. (Sze), 13.54
Az api dokumentációban ez tényleg benne van, ezért először nem is értettem, miért vagy csalódott a Gears esetében, de így teljesen érthető.

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

Re: Nem eszik olyan forrón

Fraki · 2009. Május. 11. (H), 13.40
„Mégpedig melyeket?”

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

Értelmezz, ne forgass ki

Joó Ádám · 2009. Május. 11. (H), 14.19
A natívat és a stilizáltat.


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.

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.


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.

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


Nem, abban nem vagyok biztos, hogy pontosan mi, de egy biztos: nem hivatkozások, márpedig a HTML-ben csak hivatkozások vannak.

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.


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.

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


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.

Nem. A szabványt nem minősíti az, hogy egy ráépülő keretrendszert használok


Kivéve ha a keretrendszert nem plusz funkcionalitás, hanem a szabvány kiváltására használom.

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.


Argumentum ad nausam, ismét.
31

Hagyhatjuk a natív

Fraki · 2009. Május. 11. (H), 16.18
Hagyhatjuk a natív kifejezést, de még mindig két külön dologról beszélünk. A webes navigáció sokkal szerteágazóbb és kreatívabb terület, mint az alkalmazásoké (ahol nem jellemző szempont a stilizálhatóság), nem értem, miért kell az egyiket a másikra erőltetni, akár fogalmi szinten is.

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

menüzuldomdzséjkverirubikszemel

Joó Ádám · 2009. Május. 11. (H), 16.57
A webes navigáció sokkal szerteágazóbb és kreatívabb terület, mint az alkalmazásoké (ahol nem jellemző szempont a stilizálhatóság)

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.

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.

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

Vagy szerinted akar? Fenntartom a kérdésem a weblaborral kapcsolatban. Mi a gond azzal? Csak annyi, hogy UL helyett MENU tag kellene?

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.

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.

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.

Egyáltalán nem értem, hogy a DOM-jQuery témától hogy jutottunk el a rubys XML-feldolgozásig.

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.

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

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…

Nem tudom, miért mondod ezt, nem is reagáltál rá. Az, hogy ezek a keretrendszerek versenyeznek, az fontos.

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

"csak hivatkozás"

Hodicska Gergely · 2009. Május. 11. (H), 22.45
márpedig a HTML-ben csak hivatkozások vannak.
Meg mondjuk listák, a menü pedig hivatkozások listája. :)
37

Nem hivatkozás, nem lista

Joó Ádám · 2009. Május. 11. (H), 23.23
A hivatkozás az hivatkozás: utalás egy erőforrásra a szövegben, melyhez elhagyható metainformációként hozzáfűzöd a webcímét. Tipikusan a „lásd a C függeléket” típusú dolgok, amiket aztán ki lehet terjeszteni külső dokumentumokra is. Azonban ettől igen távol állnak pl. itt a hozzászólások alján megjelenő linkek, amik a válasz vagy a szerkesztés űrlapra dobnak, mert ezek bizony gombok, ezek pedig ismét olyasmik, amik hiányoznak a HTML-ből.

A vízszintesen egymás mellé igazított elemek pedig nem alkotnak listát abban az értelemben, ahogy a HTML definiálja azt.
39

????

Hodicska Gergely · 2009. Május. 12. (K), 00.46
A hivatkozás az hivatkozás: utalás egy erőforrásra a szövegben
Ezt honnan szeded? A link egy tetszőleges erőforrásra mutat, pontosan ahogy a weblabor "menüjében" a Blog link/menüpont.

itt a hozzászólások alján megjelenő linkek, amik a válasz vagy a szerkesztés űrlapra dobnak
Sima horgonyok, érdekes módon a link tagről szóló w3c oldalon lehet erről olvasni.

mert ezek bizony gombok, ezek pedig ismét olyasmik, amik hiányoznak a HTML-ből.
Nem látom be, hogy ezek mitől gombok, de ezt felejtsük el, ettől függetlenül van gomb a HTML-ben.

A vízszintesen egymás mellé igazított elemek pedig nem alkotnak listát abban az értelemben, ahogy a HTML definiálja azt.
Ezt szintén honnan szeded? Sem a szöveges leírásban, sem a DTD-ben nincs ilyen.
50

Hivatkozások, gombok, listák

Joó Ádám · 2009. Május. 19. (K), 01.43
Ezt honnan szeded? A link egy tetszőleges erőforrásra mutat, pontosan ahogy a weblabor "menüjében" a Blog link/menüpont.

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.

ettől függetlenül van gomb a HTML-ben.

Csak űrlapokhoz. Én a klasszikus anchort viselkedést hiányolom, épp csak egy alkalmazásokban használatos gomb szemantikájával.

Ezt szintén honnan szeded? Sem a szöveges leírásban, sem a DTD-ben nincs ilyen.

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

egyértelmű utalás

Hodicska Gergely · 2009. Május. 19. (K), 16.27
Már önmagában is kicsit furcsa szóösszetétel :), de kíváncsian várom az egyértelmű utalásokat.
30

Adatvédelmi problémákat vet fel

prom3theus · 2009. Május. 11. (H), 15.33
Szerintem a főprobléma alapvetően személyi jogi. Adatvédelmileg aggályos, ha egy alkalmazás csak úgy, minden szó nélkül hozzáfér a géped teljes tartalmához. Itt nyilván a legszűkebb keresztmetszet elvét alkalmazzák a cégek a jogbiztonságuk megtartása érdekében. Például a magyar adatvédelmi törvények a legszigorúbbak közé tartoznak, de feltételezhető, hogy vannak a miénknél is paranoidabb országok ebben a tekintetben.

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

Off(?) Miért teszünk ki valamit a webre?

Ustak · 2009. Május. 11. (H), 21.22
Olyan szépen elvitatkoztok, hogy nem is tudom hova szóljak hozzá, úgyhogy inkább beleszólok ide a közepébe :-)
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:
platformfüggetlenségben mi vagyunk a császárok, és igenis amit text-el lehet, azt el tudjuk érni! Webfejlesztés...én így szeretlek! :-)
40

Alkalmazás

saxus · 2009. Május. 12. (K), 01.02
Jön itt mindenki azzal, hogy span, div, ul, nav, HTML element, stb. Csak épp egy kérdést felejt el mindenki feltenni:

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 ;)
44

jézus

Cadeyrn · 2009. Május. 14. (Cs), 14.44
Hogy lehet ennyire eltérni az eredeti témától?!

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

Nem teológia

Joó Ádám · 2009. Május. 19. (K), 12.50
Hogy lehet ennyire eltérni az eredeti témától?!

Egyáltalán nem tértünk el, továbbra is alkalmazások kontra webről van szó.

Ceriak: csinálj XML-ben menüt, tedd ki saját XSLT-vel a lapod, és kész, a vita el van intézve.

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

eredeti...

Cadeyrn · 2009. Május. 26. (K), 12.24
Az eredeti téma - mármint a cikk - valami olyanról szólt, hogy hogyan lehetne a gépen levő erőforrásokat, jelen esetben file-okat feltöltés nélkül webalkalmazásokkal kezelni, és ennek a témának semmi köze ahhoz, hogy van-e MENU a DOM-ban, vagy sem, hogy az XML mire jó és mire nem. Persze lehet, hogy én látom rosszul.

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.