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

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.

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

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

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ě.

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 :)

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

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.php → default.latte (výpis produktů). Dál ProductPresenter.php → default.latte. Pak je všechno jenom default.latte a špatně se v tom orientuje, ne? Jak to řešíte prakticky?

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).

@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. 2020 11:20)

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

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. 2020 13:55)

@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

@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ý).

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 Argument? Ja se ti jen snazil rozmluvit ze psr je neco s licensi…

@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

@jspetrak Základ je mít univerzální mapování presenterů (v případě z https://prnt.sc/skv2cp myslím takto *: ['App', '*', 'Presenters\*Presenter'])
Na presentery se pak dotazuješ pomocí absolutního názvu, ne relativního – :Error:default, :Admin:User:default apod.