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

• #9144 Sk8erPeter nagyúr Entrecampos #9141

  Új Válasz 2012-04-07 21:28:38 #9144

  Ú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 Entrecampos #9141 üzenetére

  "Majd egyszer mérjetek egy lefutási időt..."
  Sokkal hitelesebb lett volna a mondókád, ha valami konkrétumot is tartalmaz, nem csak levegőbe beszélést: például a saját tapasztalataidat futási időkről, esetleg konkrét mérési eredményeidet.

  "Persze, itt nem 3 elem bejárására gondoltam... Illetve 3 aktív felhasználónál. "
  Ja, mert mi eddigi életünkben 3 elemnél többet tartalmazó tömböt nem jártunk be, és elképzelésünk sincsen arról, hogy milyen is lehet, ha egy oldalon 3-nál több felhasználó is tevékenykedik egyszerre...
  Nem azért, de ekkora arccal, a többiek lebecsülésével (a másik tudásának vagy tapasztalatainak ismerete nélkül) betolni egy indokolatlanul nagyképű dumát nem túl szimpatikus kezdés a fórumon - ahogy elnézem, ebben a topicban eddig ez a kettő volt az összes termésed.
  Hidd el, hogy nagyon jó szakmai vitákat lehet folytatni itt a fórumon arcoskodás nélkül is - ha jó szakmai érvet hozol fel, elfogadjuk, de lehet, hogy vitatjuk - amivel még nincs is semmi baj, mert egy ilyen vita termékeny is lehet, mindegyik résztvevő fél tanulhat belőle a másiktól. De amiket eddig villantottál, annak alapot nem adtál, csak értelmetlenül lefitymáltad más kódját.

  Visszatérve a kérdésre:
  nagyon nem árt, ha az ember a kód rugalmasságát, átláthatóságát, módosíthatóságát, bizonyos részek egységes kezelését is az első szempontok közé helyezi.
  Például ha éppen az a cél, hogy mondjuk valamilyen formmezőket azonos módon tudj validálni, feldolgozni, azonos tömbbe tartozzanak, akkor ez a tömbös megoldás nagyon előnyös lehet, ha valaki jól írja meg, a hozzá tartozó kód gyorsan átlátható, könnyen kezelhető lehet.
  Vegyük azt, hogy mondjuk épp egy select lista klónozgatásáról van szó, előre nem lehet tudni, mennyi keletkezik, de azért ugyanezen a formon mondjuk van még 10 text field, 5 textarea, néhány radio box, checkbox, stb.
  Te meg azt mondod, hogy fúj de csúnya ez a tömbös megoldás, te úgy fogod megoldani, hogy a select listáknál mondjuk a name attribútum mögé raksz egy alsóvonás+inkrementált számot (tehát mondjuk ilyen lesz: name="list_1", name="list_2", stb.) Gondolj bele, milyen csúnya lesz ennek a szerveroldali kezelése - és mennyivel szebben kezelhető lenne egy tömbös megoldás, ahol egybetartozó elemeken rohangászhatnál végig.
  Vagy:
  a $_POST-on belül mondjuk van 100 formmező, ebből kb. 30 mondjuk a fentihez hasonlóan összetartozó, de szerinted legyenek csak széjjeldobálva, majd valami érdekes módszerrel megpróbáljuk bejárni - pl. a $_POST tömbön végigmegyünk, majd minden egyes elemre valami ellenőrzést megpróbálunk pl. a name attribútum első pár karaktere alapján ellenőrizni (vagy nem tudom, hogy gondoltad). Nem lenne szebb úgy, ha a 30 teljesen egybetartozó, hasonló módon kezelendő mező egybetartozna, és egy tömbön belüli tömb lenne? Így azonos name-en belül több field szerepelne.
  Kétlem, hogy ez a fajta a tömbbe rendezés releváns teljesítményromlást okozna.

  Remélem innentől már némi konkrétumokat is tartalmazó hsz.-eket fogsz tudni kreálni, úgy érdemben is tudnánk vitatkozni.

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