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

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

  • #3987 cucka addikt tildy #3986
    Új Válasz #3987
    Ú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

    cucka

    addikt

    válasz tildy #3986 üzenetére

    Miért haszontalan? A designernek elég a html kódhoz érteni.
    Az adatot meg megkapja.
    Eddigi tapasztalataim:
    - a dizájner nem tud html/css kódot írni, vagy tud, de az olyan, hogy inkább megírom én helyette
    - nincs dokumentálva az oldal minden egyes eleme 100%-os pontossággal
    - a pontatlan doksi és a menet közben történt változások folyamatos programozó-dizájner kommunikációt igényelnek, tesztelésnél várni kell a másikra
    - a programozó dizájner kommunikáció több időt vesz el, mint ha a programozó megírja maga a html kódot
    - a legfontosabb: a sablon csak szintaktikailag különbözik a php+html kódtól, szemantikailag nem. Tehát behozol egy új absztrakciós szintet a rendszeredbe, ami gyakorlatilag semmi másra nem jó, mint hogy bizonyos fogalmakat átnevezzen.

    Ez utóbbi a legfontosabb ellenérzésem az egésszel kapcsolatban. Gyakorlatilag mindegy, hogy a <modtagcloud> tag-et cseréled le a print_mod_tag_cloud() függvény visszatérési értékére, vagy direktben írod ki azt. Bevittél a rendszeredbe egy nagy, bonyolult, hibalehetőségeket tartalmazó modult, ami annyit tud, hogy a saját szintaxisát lefordítja php szintaxisra.

    Ami még problémás, hogy a sablonozás nem igazán felel meg az oop szemléletnek. Hiába vannak objektumaid, azok nem tudják kiírni magukat, pedig pont ez lenne a lényeg, hogy az alkalmazáslogikában az értelmes dolgokkal foglalkozz és az érdektelen dolgok legyenek megvalósítva az objektumban. Ilyen érdektelen dolog a html kiírás. :)
    Tehát ha van egy menü objektumom, akkor az be tudja tölteni az adatait, el tudja menteni az adatait, lehet menüpontot hozzáadni/törölni és ki tudja írni magát html-ben. Az alkalmazáslogikát tartalmazó file-okban nincs semmi, ami a menü belső reprezentációjával kapcsolatos, mint ahogy a sablon file-okban sem. Igazából tök mindegy, hogy az a menü honnan jön, hány szintes, hogyan van belül reprezentálva, ez nem tartozik sem az alkalmazáslogikára, sem pedig a sablonra. Ettől lesz oop-s :) .
    Ennek tükrében az általad említett tagcloud modul az nem egy 100-200 soros lineáris php szkript, hanem egy osztály. Az osztályt példányosítom, felparaméterezem, majd a sablonban szólok neki, hogy írja ki magát. Az osztály hordozható, általános. Ha valamilyen speckó viselkedésre van szükség, akkor származtatok belőle egy alkalmazásspecifikus osztályt, ahol megvalósítom a változtatásokat. Sőt, az ős osztályom származhat egy lista osztályból, ami valamilyen lista kezelésére alkalmas. A tagcloud osztálynál így csak és kizárólag a kiírást kell megvalósítanom, minden más benne van az ősben.
    Amúgy tudom, nem csak ezzel az elképzeléssel lehet jól működő weboldalt gyártani, egyszerűen csak jelezni próbálom, hogy az átlag mvc-jellegű megoldásoknál vannak jobbak is :) .

    Menünél nem tartom jó ötletnek , ha a user átír egy filet, nagyon nem, elronthatja satöbbi.
    Menüszerkesztésnél a júzer nem tudja, hogy mit ír át. Kap egy felületet színes gombokkal, amivel tudja szerkeszteni a menüjét. Az az én dolgom, hogy a változtatásokat file-ban vagy adatbázisban tárolom.

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