2. Fórumok
  3. Szoftverfejlesztés
  4. PHP programozás
  5. (kiemelt téma)
Keresés

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

  • #9144 Sk8erPeter nagyúr Entrecampos #9141
    Új Válasz #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... :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.

  • #9143 Speeedfire félisten Entrecampos #9141
    Új Válasz #9143
    Ú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

    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.

  • #9140 Speeedfire félisten Entrecampos #9138
    Új Válasz #9140
    Ú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

    Speeedfire

    félisten

    válasz Entrecampos #9138 üzenetére

    Összesen kb 100 keresési feltétel van, erre most mindre írjam meg az if-elseif-else ágat? Vagy a switch-case szerkezetet? Hát...köszi, de nem. :D

  • #9139 Sk8erPeter nagyúr Entrecampos #9138
    Új Válasz #9139
    Ú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 #9138 üzenetére

    "nagyon túl bonyolítsátok a dolgokat"
    Nekem meg nem bánTSa és nem is hasogaSSa a fülemet... :DD
    Jó kezdés volt. ;]

    A tömbös elrendezés valóban véletlenül maradt benne, és azért, mert ezt ollóztam egy korábban általam készített, formelem-klónozós scripthez tartozó markupból:
    http://jsfiddle.net/Sk8erPeter/RqYYj/
    Ha klónozod az elemeket, jobban jársz, ha nem írod felül az előző elemet, hanem lehetővé teszed, hogy a klónozott elemek is láthatók legyenek szerveroldalon... :U Valószínűleg nem azért klónozod, mert a korábbi formelemek értékét el szeretnéd veszíteni.
    Ha pedig ezáltal egy tömb keletkezik szerveroldalon, azt egy tömbbel be kell járni. Ez aztán rendkívül bonyolult. :N
    Egyébként ez a szögletes zárójeles megoldás annyit módosít a korábban írt példámon, hogy szerveroldalon nem ezt látod a $_POST-ban:
    array (
    'form_elem_select' => '- semmi -',
    )
    hanem ezt:
    array (
    'form_elem_select' =>
    array (
    0 => '- semmi -',
    ),
    )

    Az, hogy ez plusz terheléseket róna a szerverre, az egyszerűen baromság. Ha a ciklus egyetlen lépés után megáll, mert mindössze egyetlen elem található benne, akkor ez nem jelent semmiféle plusz terhelést (az, hogy mondjuk egy, a ciklus léptetéséhez felhasznált változó indexét megnöveli eggyel, talán ne vegyük a releváns "terhelés" és időtöbblet kategóriájába). Cserébe felkészülsz arra az esetre is, ha valóban több elem létezik a tömbben.
    A szögletes zárójelekkel tudod jelezni jelen esetben a PHP felé, hogy itt egy tömb következik, kezelje is annak megfelelően.

    A tömbös megoldással nincs semmi baj. Nem muszáj alkalmazni, de nyugodtan lehet. Anélkül és vele is jól működő megoldásokat lehet összehozni.
    Ha az én mondókám nem is volt számodra meggyőző, akkor példának hadd hozzam fel, hogy a Drupal előszeretettel alkalmazza a Form API-jában a mezők tömbalapú generálását. Biztos azért csinálták így, mert nem értenek hozzá... :)

    Szerk.: Egyébként kilencmillió soros if-elseif-elseif-elseif-elseif...-else megoldások helyett létezik switch-case is. Meg céltól függ, milyen ellenőrzésre van szükséged, egyáltalán mit szeretnél csinálni a kapott adatokkal.

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

Hirdetés