Jak máte kód rozdělený do modulů?

joe
Člen | 293
+
0
-

Ahoj,

vrátil jsem se k jednomu svému projektu, kde mám kód rozdělený hezky do jednotlivých modulů, možná ale až moc :-) Mám totiž například namespace app/Module/Member/Front a na této úrovni mi začínají presentery (pak to je dále členěné třeba na formuláře, komponenty, atd., o úroveň výš je „Admin“).

Super je, že mám na celý web jenom dvě routy a URL adresy mám tak, jak chci. Co mi ale hrozně vadí je, že mám tolik „Default“ presenterů, kolik je modulů a ještě víc souborů default.latte :-) takže z tohohle pohledu se v tom nedá vůbec vyznat, otázka je, co s tím?

Přejmenovat Default presentery podle názvu modulu? Budou mi pak stačit jenom dvě routy? (Možná přepisovat výchozí presenter podle názvu modulu?) Měl byste pro mě někdo nějaký tip či inspiraci, jak (třeba jinak) to řešit?

Díky moc.

Editoval joe (16. 5. 4:59)

HonzaN
Člen | 59
+
+3
-

Nepodřizuj strukturu modulů tvaru požadovaného URL, k tomu slouží router.

Komponenty a formuláře je obecně možné používat napříč moduly, takže bych je doporučoval držet jinde.

CZechBoY
Člen | 3605
+
+2
-

Taky nemusi byt kazda slozka hned novy Nette modul…

joe
Člen | 293
+
0
-

HonzaN: Z ceho usuzujes, ze podrizuju strukturu pozadovane URL? Ja jen nechtel mit pro kazdy takovy modul routu.

Ja ten modul tehda pojal tak, ze by to byl treba Git submodul (ano, i ted se mi vic libi Git submodul nez balicek pridany pres composer). Tzn. napriklad modul “Clen” / “Member”, kde bude zakladni prace s uzivatelama, od registrace, prihlaseni, vypis uzivatelu, jejich formulare… a i ted po letech mi to prijde jako spravna myslenka, kdy za pomoci jenom dvou rout ziskam funkcni vsechny moduly na prijemne a pro me logicke adrese (uzivatele a uzivatele/243-nick).

Takovy modul pak jednoduse prenesu do jineho projektu, aktualizuju a bude fungovat. Zkusil jsem to resit pomoci globalnich filtru a zprovoznil jsem to, jenom “nevyhoda” pri tvoreni odkazu na vstupni presenter modulu je, ze jsou ve tvaru :Member:Member:

F.Vesely
Člen | 358
+
0
-

Ja jedu oddeleny Model od UI, takze mam App\Model\Members, App\UI\Front\Members a App\UI\Admin\Members.

Taky jsem chtel mit App\Members a pod tim Model a UI s tim, ze z toho budu mit balicek. Ale proste v zadnem projektu to neni nikdy stejne, nekdo tam chce mit email, nekdo nick, atd.

Front je pak u kazdyho projektu uplne jinej, treba na Homepage jsou vetsinou data ze 3 a vice modulu (Aktuality, Ankety, Produkty, atd.) a kam bych to asi tak mel zaradit?

joe
Člen | 293
+
0
-

F.Vesely

To máš pravdu, že častokrát to není stejné, pokud se tvoří hodně projektů. Taky jsem pracoval na místech, kde každý projekt byl trochu jinak. Ale řešil bych to tak, že existuje nějaký základ, z toho se vyjde (a jestli je to potřeba upravit, tak to buď bude napsané tak, že mi to umožní změny a nebo to nebude zpětně kompatibilní).

Já se pak v projektu líp orientuju a hned vidím, co kam patří.

HonzaN
To, že mám komponenty a formuláře v různých modulech mi přece nebrání je použít v jiných, vůbec tím limitován nejsem.

Jaké jiné řešení bys tedy doporučil?

Pokud bych chtěl například:

  • UserPresenter – URL /uzivatele
  • UserPresenter – URL /uzivatele/123-nick
  • [User]RegistrationPresenter – URL /uzivatele/registrace
vladimir.biro
Člen | 124
+
0
-

Ja mam treba u klasickeho webu, jako treba eshop s administraci frontend delany primo, jakoby bez modulu …

$shop = new RouteList()

… a Administraci pak jako modul …

$backend = new RouteList(‚Admin‘);

… podle toho mam i adresarovou sturkturu.

Delam to tak jednoduse proto, ze kdyz jsem mel modul eshop a modul admin, tak jsem to tak mel i rozdelene do adresaru (co je teda pravda ze asi byt nemusi), a pak jsem se musel hluboko preklikavat, co nemam moc rad.

V modulu Admin mam pak jen Components + Presenters a v nem Templates

Zdeno1981
Člen | 93
+
0
-

Ahoj @vladimirbiro,

jak píše @CZechBoY a @joe

Mám udělaný pouze základ projektu, kde mám 2 základní moduly Front a Backend a podle potřeb to rozšiřují a pokud to není nutné tak nevytvářím zbytečně další adresáře…

Kdysi jsem měl něco podobného, každý modul jsem měl zvlášť a v něm vše co potřebuje, co mě na tom nejvíce štvalo bylo to hluboké rozklikávání, dlouhý strom adresářů a nepřehlednost, tak jsem si udělal jen dva základní moduly, 2 routy a namespace u modulů mám jen Module/Front, Module/Admin. Vše má své výhody a nevýhody a záleží hlavně na tom, jak to bude vyhovovat tobě.

alternativní text
vladimir.biro
Člen | 124
+
0
-

Zdeno1981 napsal(a):

Ahoj @vladimirbiro,

jak píše @CZechBoY a @joe

Mám udělaný pouze základ projektu, kde mám 2 základní moduly Front a Backend a podle potřeb to rozšiřují a pokud to není nutné tak nevytvářím zbytečně další adresáře…

Kdysi jsem měl něco podobného, každý modul jsem měl zvlášť a v něm vše co potřebuje, co mě na tom nejvíce štvalo bylo to hluboké rozklikávání, dlouhý strom adresářů a nepřehlednost, tak jsem si udělal jen dva základní moduly, 2 routy a namespace u modulů mám jen Module/Front, Module/Admin. Vše má své výhody a nevýhody a záleží hlavně na tom, jak to bude vyhovovat tobě.

alternativní text

Takhle jsem to taky delaval, ale pak me stvalo, tak jsem zacal pouzivat tuhle strukturu:
https://prnt.sc/skv2cp

Hlavni web je hned v app a admin je ve vlastnim adresari

Zdeno1981
Člen | 93
+
0
-

jasně, proč ne, jen si dej pozor na velké názvy adresářů pokud k ním zadáváš cestu. Vzpomínám na kolegu, který vyvíjel na windowsu a po přesunu projektu na linux mu to nenašlo cesty k šablonám od komponent a docela s tím bojoval :)

joe
Člen | 293
+
0
-

Zdeno1981

Velké názvy adresářů jsou správně – PSR 4 :)

Díky, ono má všechno svá pro a proti, prakticky se vůbec neproklikávám nikam, na otvírání souboru používám zkratku v IDE.

vladimir.biro
Člen | 124
+
0
-

Zdeno1981 napsal(a):

jasně, proč ne, jen si dej pozor na velké názvy adresářů pokud k ním zadáváš cestu. Vzpomínám na kolegu, který vyvíjel na windowsu a po přesunu projektu na linux mu to nenašlo cesty k šablonám od komponent a docela s tím bojoval :)

Ja s tim problem nemam … Vyvyjim na MAC a na hostingu jsem zatim probelm nemel, ale jednou po mne kolega, ktery bezi na linuxe delal na projektu a dost nadaval no :D

vladimir.biro
Člen | 124
+
0
-

joe napsal(a):

Zdeno1981

Velké názvy adresářů jsou správně – PSR 4 :)

Díky, ono má všechno svá pro a proti, prakticky se vůbec neproklikávám nikam, na otvírání souboru používám zkratku v IDE.

Ano, to je pravda … tiez som si navykol na tento system. PHP Storm ma vela roznych premerovavacov na konktrentu fuknciu.

joe
Člen | 293
+
+1
-

Ještě to tu trochu oživím, pokud se snažím psát presentery tak, aby toho v nich bylo co nejméně, pak ke každému takovému presenteru náleží šablona default.latte. Pokud uvedu na příkladu eshopu, tak třeba CatalogPresenter.phpdefault.latte (výpis produktů). Dál ProductPresenter.phpdefault.latte. Pak je všechno jenom default.latte a špatně se v tom orientuje, ne? Jak to řešíte prakticky?

IJVo
Člen | 27
+
0
-

@joe v dokumentaci to není zcela vysvětleno.

Je to asi takhle:
Máš presenter, např. ProductPresenter a akci (view) show, pak presenter má název ProductPresenter.php a šablona má název show.latte.
Ale v presenteru musíš použít místo metody action() metodu actionShow() a místo metody render() metodu renderShow().
V dokumentaci viz zde https://doc.nette.org/…0/presenters#…
a zde https://doc.nette.org/…0/presenters#…

joe
Člen | 293
+
+2
-

IJVo
(Myslím, že za těch 10 let, co Nette znám, to už mám trochu naučené :-D)
Ale děkuji, já to nenapsal úplně jasně. Jde mi o to, že pokud udělám co nejmenší presentery, třeba Homepage, Article, ArticleList, About, Contact, tak ve výchozím stavu mají jako view šablonu default.latte. A pak když chci v IDE do nějaké šablony, mám vypsáno třeba 30 souborů, které se jmenují default.latte. Proto by mě zajímalo, jak toto kdo řeší. Možná by bylo lepší mít název šablony jako název presenteru. (Koukám po takovém best practice).

Mysteria
Člen | 778
+
0
-

A nestačí je jenom nepojmenovávat default.latte, ale jakkoliv jinak? Pak pořád můžeš mít na jeden presenter jednu akci, ale zároveň nebudeš mít 30× default.latte. Nikdo ti přece nebrání mít v ArticleListPresenter.php metodu renderArticleList(…).

Btw jakou výhodu podle tebe má mít jenom jednu akci v presenteru? Já to vždy dělal tak, že když jsem měl třeba ProductPresenter, tak má v sobě metody jako renderList, renderDetail, renderCreate/Update atd. Co má za výhodu mít na to samostatnej presenter?

Mistrfilda
Backer | 65
+
0
-

@joe
Já jsem si docela oblíbil šablony pojmenovávat ve formátu Homepage.default.latte nebo treba Article.show.latte (presenter.view.latte). Funguje to bez jakéhokoliv nastavování. Je to podle mě přehlednější a vyhledávání v IDE je lehčí :)

Editoval Mistrfilda (28. 6. 11:20)

joe
Člen | 293
+
0
-

Díky, ten delší způsob pojmenování se mi tolik nelíbí, i když je to taky cesta. Pořád to je taková honba za dokonalostí a tím, co se mi bude líbit :) asi si to vymyslím tak, že

HomepagePresenter (akce default) → homepage.latte
ArticleListPresenter (akce default) → articleList.latte
ArticleListPresenter (akce top) → articleList-top.latte

a podobně u komponent

UserBoxControl (render default) → userBox.latte (použití {control userBox})
UserBoxControl (render mini) → userBox-mini.latte (použití {control userBox:mini})

(když budu hledat „articlelist“, tak mi IDE napoví jak presenter, tak jeho šablony, to je pro mě asi ideální)

Šaman
Člen | 2452
+
0
-

Tomu default docela doporučuji se vyhnout. Je nicneříkající.

David Matějka
Moderator | 6230
+
+6
-

@Mysteria

Btw jakou výhodu podle tebe má mít jenom jednu akci v presenteru?

mas mensi a prehlednejsi presentery, mas tam pouze zavislosti/komponenty/signaly pro tu danou akci a ne pro 5 dalsich.


Tak z meho pohledu:

  • nedodrzuju PSR4
  • pouzivam melkou strukturu modulu (tedy jen admin/front, pripadne dalsi „entrypointy“)
  • ale v nich si delam slozky, jak uznam za vhodne (takze si tam udelam slozku „Product“, kam nahazim vsechny presentery, ktery souviseji s produkty)
  • pouzivam single action presentery – mam i zakazane jine nez default akce (kontrola ve startupu). porad se ale muze zmenit view
  • mam upraveny formatovani action a render metod, aby tam nebyl ten suffix „default“
  • mam upraveny formatovani nazvu sablon a povoluju pouze jeden format (podobne jako pise @joe), tedy pro ProductDetailPresenter je sablona ProductDetail.latte v pripade default view, pokud view zmenim, tak ProductDetail-foo.latte
  • k layoutu mam presne zadefinovanou cestu v base presenteru
  • (ty posledni dva body, krom toho, ze vyzaduji konzistenci, tak maji i pozitivni dopad na vykon, jelikoz se nemusi delat IO operace)
Šaman
Člen | 2452
+
+1
-

Snažím se, aby presenter dělal jen jednu věc. Ale, pokud se bavíme o takové té klasické „ORM“ struktuře, tak za tu jednu věc považuji starat se o jednu entitu.
Takže (klasický profláklý příklad) jeden presenter řeší třeba články.
ArticlePresenter
 – (action/render) preview na adrese Article:preview, tedy article/preview
 – detail
 – new
 – edit
 – delete (toto je handle)
Kromě toho obsahuje createComponentNewForm a createComponentEditForm. Formuláře se vytvářejí v externí továrně a data zpracovává model. Takže presenter dělá jen prostředníka mezi modelem a šablonou, řeší flashmessages, občas jazyk a ajax.


V čem doteď nemám jasno, jestli je lepší mít i metodu list (Article:list), tedy seznam článků. Anebo mít samostatny ArticlesPresenter, který má typicky jen ten jeden pohled list.

Výhodou všeho v jednom presenteru je, že z výpisu článků mohu volat handleDelete, což v externím presenteru nejde (nešlo? už jsem na to nějakou dobu nekoukal). Edit: Jop, odkaz na signál z jiného presenteru nejde. Takže je potřeba napsat si signál v ArticlesPresenteru, což je ale už zase práce s jedním článkem, nikoliv kolekcí.

Nevýhodou je, že už je to přecijen něco jiného. Kolekce článů, filtrování, listování, gridy – to všechno už s článkem jako takovým nemá moc společného. A ten jeden presenter tím docela nabobtná. (I když stále má okolo 100 řádků, pokud tam není nějaké složité řešeni ajaxu, nebo nějaké triggerováni formulářů na základě persistentních parametrů apod.)

Editoval Šaman (30. 6. 13:55)

joe
Člen | 293
+
0
-

David Matějka

PSR4 beru jako standart, je nějaký důvod nedodržovat?

Jinak mi přijde, že dává Nette dost na výběr, na jednu stranu to je super :-), ale na druhou, že není nic striktního a všichni to nepíšou stejně (zase ale chápu, že se někomu může líbit jiný způsob a nakonec pro každý případ se může hodit zvolit trochu něco odlišného).

Šaman

Řešení traitama se ti v tomto případě nelíbí? Už to trochu ztrácí na jednoduchosti. Případně nějakým CUD presenterem, ale od toho se ustupuje, co jsem tak pochopil.

David Matějka
Moderator | 6230
+
+2
-

@joe je nějaký důvod (krom toho, že je to standart) to dodržovat? :)

ne a vážně – dodržovat PSR dává smysl hlavně u opensource projektů, aby to přispěvatelé měli snažší. u vlastního kódu se snažím, abych to měl snažší já. a některé z výhod, které z toho plynou:

  • snažší refaktoring – když to přesunu do jiný složky, tak se nemusím starat o změnu namespace
  • méně importů
  • díky té mělké struktuře namespace máš často unikátní názvy tříd a snadněji se v nich tak naviguješ – nemusíš zkoumat, v jakém namespace jsou
uzziel
Člen | 54
+
-8
-

David Matějka napsal(a):

@joe je nějaký důvod (krom toho, že je to standart) to dodržovat? :)

ne a vážně – dodržovat PSR dává smysl hlavně u opensource projektů, aby to přispěvatelé měli snažší. u vlastního kódu se snažím, abych to měl snažší já. a některé z výhod, které z toho plynou:

  • snažší refaktoring – když to přesunu do jiný složky, tak se nemusím starat o změnu namespace
  • méně importů
  • díky té mělké struktuře namespace máš často unikátní názvy tříd a snadněji se v nich tak naviguješ – nemusíš zkoumat, v jakém namespace jsou

A já myslel, že PSR je standart, aby se v kódu šlo vyznat bez ohledu na typ licence.

uzziel
Člen | 54
+
-8
-

Když už egoistický mínusujete, můžete uvést důvod…

CZechBoY
Člen | 3605
+
+1
-

@uzziel doporucuju minimalne zkouknout homepage projektu :)
https://www.php-fig.org/psr/

joe
Člen | 293
+
+3
-

@DavidMatějka Tak mně to s tím PSR4 přijde přehlednější, že to dá aspoň nějaký řád do kódu, bez ohledu na to, o jaký projekt jde. Prostě je to pro mě určitý pořádek, stejně jako pojmenování souboru podle názvu třídy, tak i namespace podle aktuálního umístění. Pokud je to všechno v jednom namespace, ale rozmístěno do složek, jednoduše může dojít kolizi názvů. A u většího projektu, kde je souborů třeba přes 300 mi to prostě dává smysl (a nikdy nevím, kdy se z jednoduchého projektu stane složitý).

stepos2
Backer | 11
+
0
-

@Šaman Odkaz na signál v jiném presenteru sice nejde, ale jde udělat odkaz na signál v jakékoli komponentě. To znamená vytvořím si např. ArticleDeleteButtonControl, ve kterém bude handleDelete. A tu komponentu si přidám do ArticlePresenteru pro daný článek. V ArticlesPresenteru si vytvořím přes Multiplier jednu pro každý článek, kde je potřeba.

uzziel
Člen | 54
+
-1
-

joe napsal(a):

@DavidMatějka Tak mně to s tím PSR4 přijde přehlednější, že to dá aspoň nějaký řád do kódu, bez ohledu na to, o jaký projekt jde. Prostě je to pro mě určitý pořádek, stejně jako pojmenování souboru podle názvu třídy, tak i namespace podle aktuálního umístění. Pokud je to všechno v jednom namespace, ale rozmístěno do složek, jednoduše může dojít kolizi názvů. A u většího projektu, kde je souborů třeba přes 300 mi to prostě dává smysl (a nikdy nevím, kdy se z jednoduchého projektu stane složitý).

Však o tom to je.

Prostě používej PSR, dřív nebo později se ti to vyplatí.

uzziel
Člen | 54
+
-6
-

CZechBoY napsal(a):

@uzziel doporucuju minimalne zkouknout homepage projektu :)
https://www.php-fig.org/psr/

To je argument jak noha…

CZechBoY
Člen | 3605
+
0
-

@uzziel Argument? Ja se ti jen snazil rozmluvit ze psr je neco s licensi…

uzziel
Člen | 54
+
0
-

CZechBoY napsal(a):

@uzziel Argument? Ja se ti jen snazil rozmluvit ze psr je neco s licensi…

To rozmluv @DavidMatějka , ten psal, že PSR dává smysl hlavně u open-source.

David Matějka
Moderator | 6230
+
+1
-

@uzziel

What are the aims of the PHP-FIG?
The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we’re very aware that the rest of the PHP community is watching. If other folks want to adopt what we’re doing they are welcome to do so, but that is not the aim. Nobody in the group wants to tell you, as a programmer, how to build your application.


on teda i ten název té pracovní skupiny by ti mohl napovědět: PHP Framework Interop Group

MajklNajt
Člen | 359
+
0
-

@CZechBoY @DavidMatějka že sa vám s tým čurákom chce stále naťahovať :) všetci predsa vieme, o čo mu ide…

uzziel
Člen | 54
+
-4
-

MajklNajt napsal(a):

@CZechBoY @DavidMatějka že sa vám s tým čurákom chce stále naťahovať :) všetci predsa vieme, o čo mu ide…

Argumenty došly?

uzziel
Člen | 54
+
-3
-

David Matějka napsal(a):

@uzziel

What are the aims of the PHP-FIG?
The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we’re very aware that the rest of the PHP community is watching. If other folks want to adopt what we’re doing they are welcome to do so, but that is not the aim. Nobody in the group wants to tell you, as a programmer, how to build your application.


on teda i ten název té pracovní skupiny by ti mohl napovědět: PHP Framework Interop Group

Možná, kdyby si svůj pohled na PSR charakterizoval jinak než „dodržovat PSR dává smysl hlavně u opensource projektu“, tak by to dalo větší smysl.

Programoval si někdy v týmu nebo pracoval na větším projektu, že máš tenhlé názor na PSR?

U nás se vývojáři střidaj, podle toho kdo má čas a bez PSR by se z toho stál guláš.

Pavel Kravčík
Člen | 1025
+
+6
-

uzziel napsal(a):

Když už egoistický mínusujete, můžete uvést důvod…

Dal jsem mínus, informační hodnota těch příspěvků je 0. Spíš mínus. Fakt nechápu anonymní lidi, kteří mají potřebu volit konfrontační formu a každý druhý příspěvek je urážka cizího názoru. Diskuze vypadá jinak. Ať nováčci, kteří sem zavítají, vidí, že tohle tady není standardní chování.

OT: Dovolím si použít hlášku z divadla Sklep… já kdybych napsal něco takového, tak bych se pod taky nepodepsal.