Autor Zpráva
rixi
Profil
Ahoj,
robim webove stranky cez php a s OOP len zacinam. Napriek tomu by som navrhnut webovu aplikaciu uz v OOP, preto by som chcel poradit, co si o naslednom navrhu myslite.

Site by pouzivala 5 priecinkov: "data" (fotky z galerie, subory downloadov,..), "gfx" (css a obrazkove casti stranky, bg,..), "lib" (tinymce, smarty, lightbox a ine kniznice), "src" (php classy) a "tpl" (sablony). Podstatne je vsak navrhnutie ako bude fungovat PHP.

V priecinku "src" by boli ulozene php class subory (jedna trieda = jeden subor). Kazdy typ stranky (hlavna stranka, zobrazenie danej rubriky, stranka s registraciou a pod...) by mala kazda vlastnu triedu, v ktorej by boli napisane potrebne metody pre spracovanie obsahu a deklarovanie (assignovanie) vystupnych hodnot do sablon (napr. smarty).
Predkom vsetkych tychto tried by bola abstraktna trieda, v ktorej by sa udrziavali vsetky nastavenia sajty, teda hodnoty konstant, premennych, v konstruktoru a desktrutoru by bola inicializiacia a ukoncenie mysqli, inicializacia smarty a nakoniec nejake protected metody (funkcie), ktore by spolocne dedili vsetky jednotlive stranky (classy) podla potreby.

Nasledne index.php by uz obsahoval len autoload na volane triedy a potom by sa uz podla toho zobrazila sablona z volanej triedy.

Dufam ze som sa vyjadroval jasne a nebolo problem mojim myslienkam porozumiet :)
Alphard
Profil
rixi:
Ještě než budeme rozebírat výhody a nevýhody. Znáte alespoň základy MVC (vůči kterým se vymezujete), nebo nic jiného neznáte a rozhodl jste se "vymyslet to sám"?
V podstatě váš systém MVC již do jisté míry připomíná, ale jsou navržené změny, u kterých si nejsem jist, jesli jsou ku prospěchu.
rixi
Profil
Alphard:
MVC dokladne nepoznam, ale cital som uz o tom nieco a mam priblizne predstavu, o com to je. Mozno aj vdaka tomu moj model je, ako vravite, velmi podobny a je pravdou ze som si ho "vymyslel sam", nakolko MVC mi v praxi este vela nehovori. Takze mi zrejme doporucujete literaturu o MVC a vydat sa toutou cestou s vyuzivanim uz zauzivanych MVC architektur.
Alphard
Profil
Neříkám, že MVC je dogma, jen se ptám, jestli si jste vědom rozdílů a máte pro ně důvod.
Ve vašem návrhu se mi hlavně zdá nedostatečné členění adresáře src. Na veškeré PHP scripty, navíc vhledem k tomu, jak členíte zbytek, je to docela málo. To všechny použité knihovny (library), třídy modelu (model) a navíc třídu pro každou stránku (controller) dáte na jednu hromadu?
A pak také ten záměr 1 stránka = 1 třída. Osobně bych preferoval zažité členění controller = třída a v ní více akcí = metod.
Berte to ale jako můj subjektivní názor.
Mastodont
Profil
Já tedy hlavní problém vidím v tomhle:
Predkom vsetkych tychto tried by bola abstraktna trieda, v ktorej by sa udrziavali vsetky nastavenia sajty, teda hodnoty konstant, premennych, v konstruktoru a desktrutoru by bola inicializiacia a ukoncenie mysqli, inicializacia smarty a nakoniec nejake protected metody (funkcie), ktore by spolocne dedili vsetky jednotlive stranky (classy) podla potreby.
Nevidím důvod, proč by všechny třídy měly dědit nastavení webu.
rixi
Profil
Mastodont:
Nevidím důvod, proč by všechny třídy měly dědit nastavení webu.
Mozno som sa len zle vyjadril. Tie "nastavenia webu" som myslel vlastne hodnoty konstant (root url, umiestnenia na priecinky, databazove spojenie, atd,.. A to je vlastne myslim ze potrebne nacitavat pri kazdej stranke/pri kazdom jej nacitani.

Alphard:
To všechny použité knihovny (library), třídy modelu (model) a navíc třídu pro každou stránku (controller) dáte na jednu hromadu?
Jasne. V tejto jednoduchej aplikacii ma to napadlo zatial len takto navrhnut, ze controllery a modely v jednom adresari oddelim tak, ze model bude pomenovany ako class.Page.php a jednotlive controllery budu pomenovane ako page.Index.php, page.Register.php, atd,..
Kazdopadne dakujem za vase pripomienky, stoji za uvahu controller prerobit do jedneho. MVC si este prestudujem, nateraz som aspon pochopil rozdiel medzi controllerom a modelom. diky :)

Este by ma zaujimalo, ci moj model pripomina nejaky z MVC vzorov? Pokial ma moj k niektoremu z nich blizko, rad by som pochopitelne dodrziaval. V tejto diskusii som sa docital o prikladovych Factory a Singleton, ale ako ich architektura vyzera, k tomu som sa este nedostal.
Alphard
Profil
rixi:
V tejto diskusii som sa docital o prikladovych Factory a Singleton, ale ako ich architektura vyzera, k tomu som sa este nedostal.
:-) Mícháte jablka a hřušky dohromady. Tyto návrhové vzory jsou úplně něco jiného.

Teorie MVC (a dalších) na http://zdrojak.root.cz/clanky/uvod-do-architektury-mvc/.
Asi bych ale nejdříve doporučil projít http://doc.nette.org/cs/quickstart/vytvoreni-presenteru (manuál Nette, které používá MVP, tj. místo controlleru má presenter, ale to je detail).
rixi
Profil
No ano, MVC v zaciatkoch viac zmatenia ako pochopenia, dakujem za links :)
AM_
Profil
rixi:
Nevidím důvod, proč by všechny třídy měly dědit nastavení webu.
toto bych spíše umístil do nějaké statické třídy (např. Config::$db, Config::$url atd...), ano, je to potřeba přístupné odevšad, ale není důvod, aby to dědily všechny objekty. Ikdyž je potřeba uvážit rozdíly mezi nastaveními. Např. URL stránky bude jistojistě při každém načtení jen jedna, čili ta určitě patří někam staticky, ale připojení k databázi vůbec nemusí být globální a viditelné všude (to je jen takové dogma, protože obvykle jedno stačí a používá se na mnoha místech aplikace, ale nemusí tomu tak být vždy).

V tejto diskusii som sa docital o prikladovych Factory a Singleton
Singleton je dobrá věc. dibi::query() místo lovení někde nějaké instance připojení.
Je to vlastně jedna z realizací object factory, v jednom framewoku jsem se setkal s dobrým nápadem: Factory::call('myClass') vrací vždy jednu singleton instanci myClass, pokud ještě neexistovala, tak ji vytvoří. Dá se tak vlastně pro zavedení singleton vytvořit jedna třída a nemusí se řešit psaní statických metod ve všech třídách (ikdyž v PHP 5.3 by to pomocí __callStatic šlo vyřešit ještě elegantněji - všechna statická volání převádět na nějakou interní singleton instanci).

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: