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

• martonx veterán

  #4393

  #4392 Sk8erPeter

  2014-10-01 17:40:09

  Új Válasz

  Ú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

  

  martonx

  veterán

  #4392 Sk8erPeter

  #4392 Sk8erPeter

  Pedig annyiból nem mondott hülyeséget, hogy valóban megakadályozhatja egy form elküldését, ha mondjuk a submit buttonre (buttonökre) van kötve az event handler, és hív egy event.preventDefault()-ot; ugyanígy a linkre is igaz. Mondjuk annyiból nem volt pontos a meghatározása, hogy a metódushívás inkább az eventet érvényteleníti/törli, DE az esemény további felszivárgását nem akadályozza meg. Szóval tulajdonképpen az alapértelmezett viselkedést lehet vele módosítani, úgyhogy nagyon nem lőtt mellé. Vagy csak most hirtelen nekem nem ugrik be, mire gondoltál.

  (#4372) Zedz :
  Szívesen ránéztem volna, de törölted a kódodat pastebinről, úgy meg nehéz.

  (#4381) PumpkinSeed :
  "Azért lokálisan tesztelek webszerver nélkül, mert órai feladatra készül és ott nem szabad olyan kódot alkotni ami webszerver nélkül nem működik"
  Jézusom, milyen degenerált módszer. Ahelyett, hogy ahhoz szoktatnának, amit az ember élesben és a gyakorlatban használ... Azért ha webfejlesztésről van szó, talán nem a lokális, webszerver nélküli tesztelést kellene erőltetni. Kíváncsi lennék, mégis mi az oka, hogy így találták ki a házit nektek...
  Amúgy tényleg elkeserítő, hogy csomó visszajelzés alapján azt hallani, hogy ezek a tanfolyamok vagy elavultak, vagy valami kicsavart gondolkodás mentén elcseszik az oktatás módját.

  (#4388) martonx :
  "Simán lehet, hogy a szerver oldalon van valami elcseszve (mondjuk a legtriviálisabb dolgokat is sql-ből kérdezgeti le, erre nagyon jó tipikus rossz példa a cms-ek működése), [...]"
  Mondjuk a CMS-nél is egy normális fejlesztő JavaScript-fájlokat szerkesztget, nem inline kódokat tol fel az adatbázisba, úgyhogy szerintem ez rossz példa, mert a fejlesztői gányolásokért nem a CMS a hibás. (Bár való igaz, hogy sokszor lehetőséget is ad rá.)
  Félreértés ne essék, tény, hogy a CMS sok mindent tölt be adatbázisból, ahogy ezt sok topicban átrágtuk, de a CMS-eknél van JS-fájlok betöltéséért felelős metódus, vagy épp a modul valamely fájljában is lehet deklarálni, hogy mely JS-fájlokra lesz valószínűleg szükség.

  "Pedig annyiból nem mondott hülyeséget, hogy valóban megakadályozhatja egy form elküldését, ha mondjuk a submit buttonre (buttonökre) van kötve az event handler, és hív egy event.preventDefault()-ot; ugyanígy a linkre is igaz. Mondjuk annyiból nem volt pontos a meghatározása, hogy a metódushívás inkább az eventet érvényteleníti/törli, DE az esemény további felszivárgását nem akadályozza meg. Szóval tulajdonképpen az alapértelmezett viselkedést lehet vele módosítani, úgyhogy nagyon nem lőtt mellé. Vagy csak most hirtelen nekem nem ugrik be, mire gondoltál."

  Egyrészt igazad van, mert amit mondott önmagában annyira nem volt hülyeség, de nem is mondtam, hogy hülyeség. Viszont ha ehhez megnézed az adott példa kódját (hopsz most olvastam tovább a hsz-ed, és látom, hogy időközben törölte a kódot), akkor meg láthatod, hogy gyakorlatilag fingja sincs, hogy mit csinál, és mi a különbség az event.preventDefault és egy szimpla return között. Ergo fogalma sincs mit csinál, mire jó, még ha lexikálisan nézve nagyjából ismeri is a preventDefault meghatározását.

  A CMS-es megjegyzésemet félreértetted. Arra gondoltam, hogy a CMS kismillió dolgot kérdez le a DB-ből, ahhoz, hogy egy hello world oldalt kigeneráljon. Ez esetében szükséges működés, de nyilván teljesítmény optimalizáláls szempontjából rossz működés. Mondhatni szükséges rossz. De ezt már százszor kitárgyaltuk.

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