AJAX - hol is kezdjem?
2006-12-29T15:39:15+01:00
2006-12-29T23:41:13+01:00
2022-07-19T06:22:59+02:00
  • Csak sajna meg nem tamogatja minden bongeszo.

    De gyakorlatilag ha jol lattam, az csak egy url-dekodolo rutin, meg kulonbozo tipus->string string->tipus konverterek halmaza.
    Mutasd a teljes hozzászólást!
  • Kisebb adatmennyiségeknél / egyszerű adatsruktúráknál pedig a JSON kenterbe veri mindkettőt, úgyhogy ide is igaz, hogy a célhoz az eszközt...
    Mutasd a teljes hozzászólást!
  • Egy interpretalt nyelven sem lassu egy int, egy char egy string es egy string tomb valtozonak a kezelese. Ennyi kell egy csv feldolgozohoz. Egy CSV feldolgozo veges automata pedig csak egyszeru muveletek tartalmaz (int valtozo ertekadas, string-hez karakter appendalas, stringtomb elemenek ertekadas, 1-el inkrementalas, string x-edik karakterenek vizsgalata).

    Nem kell osszekeverni az interpretalt-at a lassuval. A Java is egy interpretalt kornyezet. De attol meg az egyszeru muveletek megfeleloen gyorsak. A fent emlitett muveletek JS-ben is kelloen gyorsak. Gyorsabb mint egy generikus XML feldolgozo, aminek raadasul a memoriafootprintje is nagyobb.

    Hidd el hogy nem fogsz szemmel eszreveheto sebesseg kulonbseget eszrevenni egy JS-ben irt CSV feldolgozo es egy bongeszo library-ben talalhato generikus XML parser kozott.

    Ami viszont nagyon nem mindegy, az az, hogy a szerver mennyi memoriat foglal sok szaz ilyen request parhuzamos kiszolgalasaval, valamint ezek a halon mekkora savszelesseget foglalnak.

    Harmadreszt: ki mondta hogy a JS library-jeiben levo XML parser optimalisan van leimplementalva?

    Negyedreszt: ott a split fuggveny JS-ben. Arra alapozva egesz jo CSV dekodert lehet irni... (ahol maganyos \-re vegzodik a mezo, ott a kovetkezot hozza kell csapni, ha az utolso mezo vegzodik \-re, akkor a kovetkezo sort kell hozzacsapni). De egyebkent tenyleg kenyelmesebb lenne egy C-ben leoptimalizalt CSV-split fuggveny hasznalata.
    Mutasd a teljes hozzászólást!
  • Ezzel nem értek egyet:

    A csv sor feldolgozasara lehet teljesen mezei veges-allapotautomatat irni. Az xml-re altalanos esetben veremautomatat kell, ergo ha valami JS-es xml feldolgozot hasznalsz, az garantaltan ilyesmi alapu lesz, tehat bonyolultabb az algoritmus amivel feldolgozzak, ergo a CPU-t es a memoriat jobban terhelik.


    A JS egy interpretált környezet, és egyéb okok miatt (is) lassú, mint egy kéthetes zsíroskenyér. Ebben kb. lassan dolgozol fel egy böhöm nagy CSV file-t. Az XML-t viszont a böngésző JS nélkül, natív kóddal dolgozza fel neked, böhöm nagyot is villámgyorsan ahhoz képest, amíg te JS-ből feldolgozol ugyanakkora a CSV-t. (Tegyük fel, nem <kilométer_hosszú_könnyen_olvasható> tageket használsz XML-ben egy táblázathoz, hanem <piciket>, ekkor a méretben sincs nagy eltérést egy escape-elt CSV-hez képest.) Tehát hiába gyorsabb a CSV-t feldolgozni JS-ből, mint az XML-t JS-ből, mert a CSV-t JS-ből dolgozod fel, viszont az XML-t már feldolgozta neked a böngésző, te JS-ből csak egy fát jársz be, XHTML esetén jó eséllyel még azt se. A probléma nagyjából analóg a MySQL-ből rendezzem, vagy PHP-ből problémával.

    A Smarty témánál valamit benézhettem, bocs a nehézfejűségért.
    Mutasd a teljes hozzászólást!
  • Azt eleve irtam, hogy "amennyiben csv file-al le tudod irni az adatot".

    A csv sor feldolgozasara lehet teljesen mezei veges-allapotautomatat irni. Az xml-re altalanos esetben veremautomatat kell, ergo ha valami JS-es xml feldolgozot hasznalsz, az garantaltan ilyesmi alapu lesz, tehat bonyolultabb az algoritmus amivel feldolgozzak, ergo a CPU-t es a memoriat jobban terhelik.

    Ezenkivul direkt nem a te altalad irt kod bonyolultsagat emlitettem hanem a cpu terheleset. Az fuggetlen attol hogy te irtad a kodot vagy valaki mas. Egy veges-allapotautomatat JS-ben is le lehet optimalisan kodolni.

    A Smarty vs. kezzel kiirom temara azt irtam hogy teljesen fuggetlen a kiirt adat formatumatol, nem azt hogy melyik a jobb, melyik terhel kevesbe.

    A html-re emlekezteto gondolatmenetet nem is vitatom, csakhogy csv-ben leirhato dologrol volt szo.
    Mutasd a teljes hozzászólást!
  • Az XML valóban jóval nagyobb, CSV-nél viszont ügyelni kell az escape-szekvenciákra is (\;-ket, \\-eket kezelni, sortöréseket is escape-elni, stb), ráadásul a CSV-t csak JavaScriptből tudod feldolgozni, az XML-t viszont a böngésző parsolja ki neked, natív kóddal. A Smarty vs. kézzel kiírom téma pedig megint csak sántít, mert a Smarty cache-el, a kézzel kiírás meg nem biztos.

    Ha pont táblázat típusú adatszerkezetet fogadsz, akkor a CSV jobb megoldás, ha viszont már HTML-re jobban emlékeztetőt (vagy akár XHTML-t), akkor a "hagyományos" az igazi. Már csak azért is, mert ha pl. a szerverről mondjuk formázott szöveget fogadsz, pl. egy chat esetén, akkor azt direktben, parsolgatás nélkül teheted ki pl. egy innerHTML-be, ha XHTML-ben fogadod (ami mellesleg XML is), és a böngé, akkor meg egyébként is fel kell dolgoznia a brózernek megjelenítéskor.
    Mutasd a teljes hozzászólást!
  • Egy csv file kiirasa tenyleg nem terheli feleslegesen a szervert.

    Egy xml file kiirasaval mar tobbet fog tokolni, es felesleges adatokat irsz ki (az egesz xml szintaktika felesleges adat, ha egy csv fileban ugyanugy le tudod az egeszet irni). A meret pedig xml-nel adott esetben akar ketszerese vagy meg tobbszorose is lehet, kulonosen ha nem xml attributumokba hanem xml elementekbe teszed az egyes cellakat.

    Feldolgozni szinten egyszerubb a bongeszoben a csv-t mint az xml-t (a processzor szamara marmint).

    Az meg hogy Smarty-val vagy massal csinalod annak eldonteset hogy melyik kodod az, aminek az inputot fel kell dolgozza, az ettol teljesen fuggetlen.
    Mutasd a teljes hozzászólást!
  • Nemtom, de szerintem ha egy táblázatot kiírok, kb ugyanannyira terheli a szervert, ha Smartyval írom ki vagy kiírom XMLbe és azt küldöm el. A méret is hasonló. A szervert nem terheli, max. a böngészőt. Majd tesztelgetek...
    Mutasd a teljes hozzászólást!
  • A hagyomanyok tisztelete adott esetben egy rossz megoldas.

    Tipikusan az XML feldolgozas es XML-be kiiratas altalaban (nem nagyon bonyolult adatszerkezet eseten) feleslegesen terheli a szerver es a bongeszo CPU-jat, valamint feleslegesen noveli a halozati forgalmat.
    Mutasd a teljes hozzászólást!
  • 1. Egyáltalán nem
    2. AJAX-szal nem.

    Az AJAX egy technológia, Aszinkron Javascript és XML, ami azt jelenti, hogy JavaScript-tel képes vagy a háttérben HTTP POST vagy GET kéréseket küldeni a szervernek, amire válaszként szöveges adatot tudsz fogadni, és kliensoldalon feldolgozni.

    Az már csak a JavaScript dolga, hogy mit kezd az érkezett adattal. A kapott szöveg lehet egy egyszerű "Hello World", lehet egy CSV táblázat (Comma Separated Values, pl

    Rendszám;Név;Típus ABC-123;Gipsz Jakab;Skoda Fabia HXR-1337;Leet Haxor;Trabant ...
    ), vagy akár egy XML forrás. Az már rajtad áll, hogy mit kezdesz vele, és hogyan dolgozod fel. Ha tiszteled a hagyományokat , akkor XML-t fogadsz (szerveroldalon megfelelő Content-Type és Cache fejlécekkel küldve), amit a böngésző képes neked előre feldolgozni, így neked JavaScriptből már csak egy DOM-fát kell bejárnod (lásd: linkek), majd szintén DOM és DHTML segítségével úgy jeleníted meg, ahogy akarod. A sorbarendezéshez csak annyi kell, hogy ha a user más rendezést választ, mint ami a képernyőn van, akkor (feltételezve, hogy eltároltad és megtartottad a korrában fogadott és megjelenített adatokat) te szerver és AJAX nélkül, pusztán JavaScripttel más sorrendben jeleníted meg (DHTML). Így tisztább?
    Mutasd a teljes hozzászólást!
  • Na, megnézegettem, jónak tűnik. Van néhány láma kérdésem.

    1.) Ezt a prototype js-t mindig használnom kell?
    2.) Olyat lehet csinálni, hogy mindjuk AJAX-szal sorbarendezést és keresést csinálok? Mert pl. ha kiírok egy rakat adatot a lapra, a rendezés miatt jó lenne, ha nem terhelnénk a szervert, nincs új SQL query, stb. Egy táblázatba írnám ki az adatokat. Nem kell leírni a menetet, csak 1-2 obj. nevet adjatok! Adjam át tömbben az adaokat, és azzal írassam kapásból ki?

    Mutasd a teljes hozzászólást!
  • Megérteni tényleg néhány perc, okosan megtanulni használni annál kicsit több. Az AJAX és úgy általában a rich client kialakítás szvsz sokkal közelebb áll a designhoz és a felülettervezéshez, mint a programozáshoz, ezért kicsit másként is kell hozzáállni. Amellett persze, hogy tisztában vagy a folymatokkal, és nagy forgalmú sitenál sem vágod haza a szervert, vagy nem zabálod le a kliens összes erőforrásait egy-egy működőképes, ámde átgondolatlan megoldással.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Akkor kérnék gegy DOM leírást is. A javasctipttel még valahogy elboldogulok. AZ jó ha 20 perc, akkor kb 1-2 hét alatt én is megvok vele így suli mellett
    Mutasd a teljes hozzászólást!
  • Én (meglévő JavaScript és DOM, valamint egyéb programozási nyelvek és technológiák terén szerzett elméleti és gyakorlati ismeretekre alapozva) innen körülbelül 20 perc alatt tisztába jöttem az AJAX alapjaival. Ezt nem önfényezésnek írtam, csak illusztrálandó, hogy alapvetően nem egy veszélyesen bonyolult dolog a megtanulása, ha minden más szükséges háttérinfód megvan a webfejlesztésről.
    Mutasd a teljes hozzászólást!
  • Én ebből tanultam
    Mutasd a teljes hozzászólást!
  • Sziasztok! Szeretnék ismerkedni az AJAXszal! Tudtok doksikat adni (ismerem a guglit). Magyar kellene elsősorban, de amúgy az angol is jó. Olyan kéne, amiből ki lehet indulni. A WebVilág JS Referencia könyvéből tanultam JS-t, kisebb-nagyobb sikerrel. xHTML-t használok, de nagyon alap szinten, Igaz, a lapok XHTML validak, de anno még HTML 4.0-val kezdtem, és csak néhány taget használok (html, head, meta, title, body, link, a, strong, br, em, span, div, table, tr, th, td, center), és emellé még CSS 2.0.

    PLZ HELP!
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd