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

• #3987 cucka addikt tildy #3986

  Új Válasz 2010-02-13 19:10:36 #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