Keresés

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

  • 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... :D
    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.

  • Speeedfire

    félisten

    válasz Entrecampos #9141 üzenetére

    Bocs, de nem publikus.
    A lényege, hogy sok checkbox van, select és intervallum mező, amiket valahogy fel kell dolgozni a php-val. Illetve nagyon sok nem is így van elmentve az adatbázisban.
    Gondolok itt olyanra, hogy ha ki van választva egy checkbox akkor az adatbázisban több lehetőség is lehet.
    A selectnél egyértelmű, hogy csak azok a lehetőségek vannak rá, amik az adatbázisban is fellelhetők.
    Így csak ezt találtam járható útnak.
    Nem tudom, hogy most mennyivel lenne gyorsabb az is_array helyett ha azt mondnám neki, hogy if(kb 50 elem felsorolása). :F
    Localhost alatt gyors, nem tudom mekkora terhelése lesz a rendszernek így...de...


    Lacces: Szerintem nem, ha már nagyon váltani akarsz akkor inkább már a synfony szerintem.

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