Új hozzászólás Aktív témák

• #3921 Sk8erPeter nagyúr martonx #3918

  Új Válasz 2014-02-14 11:39:37 #3921

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #3918 üzenetére

  Hát ja. Kezdőnek egyértelmű, hogy bűn jQuery-vel kezdenie, mert később már nem fogja akarni megtanulni, milyen munkafolyamatot is egyszerűsít le.
  Mondjuk szerencsére a 11-es verzió óta már az IE sem számít annyira szitokszónak, mint régen (még ha a felhasználói felület ostoba is még mindig), így ritkul az, hogy böngészőspecifikus baromságokat kelljen tákolni (lásd az IE-specifikus attachEventet régről az addEventListenerrel szemben), ezért a plain JavaScript is talán használhatóbbá kezd válni, mint régen, ami egyébként vicces helyzet, de azért még mindig sokat segít a cross-browseresítésben a jQuery... aztán az megint egy következő szint, hogy valaki értse, hogy a $('#test') és document.getElementById('test') hiába hivatkozik ugyanarra az elemre, attól még az első egy jQuery objectet ad vissza, a másik pedig egy Element objectet...
  Persze mindezek értéséhez/sejtéséhez először is tudni kellene használni a dokumentációkat, ami ahogy a topicokban észreveszem, sajnos cseppet sem magától értetődő. Meg hát érted, majd a fórumon a srácok megmondják...

  (#3919) cSuwwi :
  Sztem azért nem kopik ki, mert az onclick és többi hasonló attribútumot eleinte gyorsabb bepötyögni egyből az elemhez, és meglátni, hogy mi történik - ez a tanulási fázisban még az elfogadható érvek közé tartozik, én is így kezdtem, csak van, aki aztán megragad ezen a szinten, és azt mondja, hogy de hát így könnyebb olvasni, és egyből tudom, hogy ahhoz az elemhez milyen eseménykezelő tartozik. Na ez egy baromság. Sokkal nehezebb karbantartani egy ilyen széttákolt kódot. Eleve ott kezdődik, hogy mindegyik nyelvnek legyen meg a maga jól körülhatárolható felelőssége, ne legyen szétgányolva a JS-kód CSS-sel vagy HTML-lel se. A PHP-kódban se legyen lehetőleg stringként inline behányt JavaScript-kód. Meg hasonlók. Persze vannak fejlesztők, akik ezekre is megtalálják az önigazoló magyarázatokat, de nem ők csinálják jól.

  Szerintem erről ez egy nagyon jó összefoglaló diasor:
  Refactoring to Unobtrusive JavaScript
  http://www.slideshare.net/fgalassi/refactoring-to-unobtrusive-javascript
  (lehet, hogy meg is kérem, hogy ezt tegyék be az 1. hsz.-be, csak hogy mindenkinek szem előtt legyen, nagyon tömören elmagyarázva, mit, hogyan kéne)

  Na meg amúgy a net tele van szemétrevaló tutorialokkal is, amik a rossz szokásokat verik az emberek fejébe.

  =====

  (#3920) fordfairlane :
  Kicsit később küldtem el, mint Te, mert kotorásztam a belinkelt diasor után, így csak most látom, amit írtál, de közben Te is azt a szempontot írod, hogy látod magánál az elemnél, hogy hozzá van kötve az eseménykezelő, és az jó... de ne már.
  Ezzel nyugodtan alá lehetne támasztani azt is, hogy formvalidálásnál minden egyes inputra külön-külön dobjuk be mondjuk onblurre a validáló függvényt. Vagy akkor ez ne legyen, csak egyszer, magán a form csomóponton legyen egy onsubmit-attribútumba bedobott függvénynév, mert az épp a határon mozgolódik a tákolmány és a karbantartható kód között? Érted, ezzel a hozzáállással (mondjuk ha valaki ilyen tutorialt ír) a kezdők is kedvet kaphatnak hozzá, hogy na, akkor ilyen alapon mehet minden az attribútumokba, mert azt írták, hogy jó az, és akkor ránézek a HTML-kódra, és tök jó, hogy egyben látom a JavaScript-kódot is. De akkor ugyanígy nem lenne helytelen az sem, hogy valaki style-attribútumban határozza meg az adott elem kinézetét. Az sem magyarázható, bár elméletileg ezen az elven az is jó lehetne, mivel akkor tök jó, hogy helyben látja az illető, hogy fog kinézni az elem.

Új hozzászólás Aktív témák