Adresářová struktura pro budoucí CMS

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Tomáš Jablonický
Člen | 115
+
0
-

Ahoj,

co říci na začátek? Pro svojí práci již delší dobu používám Nette a zjistil jsem, že pro velmi rozsáhlé řešení je klasická adresářová struktura nedostačující. Stačí se podívat do adresáře modulu Admin na Presentery. Doslova pro každou část jiných modulů je zde několik Presenterů pro jejich editaci a to nemluvím o šablonách. Uvedu příklad. Mám modul Forum. Typický obsah fóra je Topic, nějaká kategorizace a kontejner do které spadají příslušné kategorie atd. Každá část by se měla nějakým způsobem editovat. Moje praxe byla následující. Pro editaci kategorií jsem vytvořil v modulu presenter CategoryPresenter a v něm příslušné Rendery Add, Edit, Default, atd. Najednou pro tento modul zde vznikli cca 3 Presentery. Takto to pokračovalo i u dalších modulů a najednou jich bylo desítky.

Moje myšlenka je, oddělit tyto Presentery od modulu Admin a mít je přímo v příslušném modulu (nechat Presentery pro Backend v modulu Forum a nikoliv v modulu Admin).

Další můj postřeh se týká šablon.Ve většině Presenterech se vyskytují Rendery Add, Edit, Default, atd. Pro tyto Rendery je potřeba vytvořit šablonu v Templates. Všiml jsem si, že se tyto šablony doslova duplikují a jejich pozdější úprava je složitější. Proč tedy takové šablony nehodit do jednoho společné složky a nebrat je odsud (viz. návrh)?

Návrh adresářové struktury:

+app\
    |+Module................................\
    |-components			    |+AdminModule.......................\
    |-presenters			    .                                   |-presenters
    |-models				    .                                   |-templates
    |-forms				    .                                   |-models
    |-databases				    |+NameModule\                       |-databases
    |+templates....\			                |+backend               |-forms
    |config.neon   |+frontend \		                |+frontend..\
    |bootstrap.php |-backend  |add.latte	        |-models    |-preseters
 		      	      |edit.latte               |-databases |-templates
   			      |default.latte            |-forms
			      |@layout.latte

Globální šablony pro Backend jsou ve složce app/templtes/backend/ a obdobně pro Frontend ve složce /app/templates/frontend/. Samozřejmě musí být zachována možnost takové šablony vytvářet pro jednotlivé moduly zvlášť. Například pro Backend modulu Name vznikne požadavek vytvořit neglobální šablonu pro Redner Add. V tomto případě by se nenačetla globální šablona add.latte z app/templtes/backend/add.latte, ale pokud by existovala šablona app/Module/NameModule/backend/templates/add.latte – pak by se načetla právě tato.

Snad nevynalézám kolo. Vím že tady na fóru je k nalezení podobná myšlenka ale nemohu to vlákno již najít.

Editoval jablon (6. 12. 2011 19:04)

JuniorJR
Člen | 181
+
0
-

Nic by ti nemělo bránit přepsat si metodu pro hledání šablon, viz. Presenter::formatTemplateFiles()

Editoval JuniorJR (6. 12. 2011 20:53)

Tomáš Jablonický
Člen | 115
+
0
-

JuniorJR napsal(a):

Nic by ti nemělo bránit přepsat si metodu pro hledání šablon, viz. Presenter::formatTemplateFiles()

Asi jsem se špatně vyjádřil. Mě jde spíš o to jestli tahle adresářová struktura je pro monstrózní projekty lepší nežli klasika.

Tharos
Člen | 1030
+
0
-

Monstrózní projekty se vyznačují tím, že jsou si jen málokdy technicky navzájem podobné a použití každé technologie či postupu by mělo být velmi dobře zváženo a podpořeno nějakou analýzou (alespoň výhody versus nevýhody) v kontextu daného projektu. Adresářová struktura, která je vhodná pro jeden takový projekt, může být totálně nevhodná pro jiný.

Tharos
Člen | 1030
+
0
-

Pro inspiraci se můžeš podívat třeba na tenhle článek. Z diskuze pod ním je vidět, jak je vhodnost určitého řešení relativní a ošemetná.