Iterování všech Presenterů

Nejpr odpovim na otazku: asi by to mohlo jit metodou findByType na Containeru (ten si injectnes jako zavislost), nette totiz hleda presentery a registruje je jako sluzby. Hledal bys dle typu Nette\Application\UI\Presenter a melo by to vratit nazvy sluzeb presenteru. Problem je, ze bys asi musel vytvorit instance te sluzby, abys vubec zjistil, o jaky presenter se jedna.

Ale nedoporucuju ti to, krom toho, ze to nebude uplne spolehlive, tak te to muze pozdeji limitovat. A jeste par poznamek:

Všechny Moduly jsou pro mě v aplikaci Presentery

tohle nedoporucuju, predpokladam, ze ty moduly mohou byt celkem rozsahle? Radeji si pro to vytvor moduly :). To je v nette logicke rozcleneni presenteru do nejakych celku, pouziti najdes v examplech: https://github.com/…odules-Usage … v tech modulech pak budes mit presentery pro jednotlive casti tech modulu, osobne doporucuji mit v presenterech pouze jednu akci.

Pro kazdy modul budes pak mit tridu registrovanou jako sluzbu, ktera by popisovala vlastnosti toho modulu a mohla by se treba vyuzit prave pro to menu nebo zjistovani pristupu. coz tedy vyresi i puvodni otazku

Řešil jsem něco podobného následovně. Každý modul má vlastní config → v boostrap se pak skládají. Pokud je zadaný parametr menu → generuje se z něj menu a kontrolují se práva. Je to pár podmínek. Výsledek se uloží někam do cache.

Modul může mít více presenterů. Zbytek se pak generuje automaticky – má uživatel práva – zobrazí se to v menu. Pokud nemá – nezobrazí se to apod. Ty pravidla si pak můžeš nastavit sám. To projíždění presenterů jsem zkoušel, jde to snadno, ale nebylo to výhodné, pokud si je chtěl nějak spojovat do bloků, nastavovat jim ikonky, barvy a třeba pravidla pro zobrazí v seznamu aplikací či různých blocích.

parameters:
    menu:
        psa:
            title: Smlouvy
            titleLong: PSA - Smlouvy
            presenter: Psa
            alias:
                - PsaContract
                - PsaNeco
            icon:
                name: file-text-o
                color: pink
            submenu:
                contract:
                    title: Seznam
                    presenter: Psa
                    action: default
                    icon:
                        name: list
                list:
                    title: Ostatní
                    presenter: PsaNeco
                    icon:
                        name: plane
                    dropbox:
                        prolong:
                            title: Prolongace smluv
                            presenter: PsaNeco
                            action: default
                            icon:
                                name: plane
                        #...

Asi jsem trochu náročnej, ale tohle řešení by mi nevyhovovalo.

Vytvoření nového modulu a jeho „zapojení“ do aplikace by vyžadovalo myslet na úpravu i tohoto configu. A nejedná se mi pouze o samotné menu.

Dejme tomu třeba vytvoření nějakého CRONu. Ano – můžu mít několik akcí v samotném spouštění a podle url spouštět jednotlivé akce v presenteru. Ale co když chci jenom spustit v cronu ⇒ aplikace/uklidPoSobe a všechny presentery budou mít spustět svoje volání? Nechci to dělat přes aplikace/Front/uklidPoSobe, aplikace/Admin/uklidPoSobe …

A v praxi člověk přijde na mnoho dalších věcí. Prostě asi je to síla zvyku, ale všechny akce, co by měl daný modul dělat by se mi moc líbilo definovat v DefaultPresenteru onoho modulu. Ať už to je definice Menu (Tvé řešení neřeší např. jazykové mutace, v cz je v sk není, ano šlo by to rozšířit, ale… to by bylo možné pak rozšířovat do nekonečna).

V principu to všechno vyřeší jedna jediná věc – mít možnost vytvoření instancí všech Presenterů a úplně dokonale pouze těch, co budou mít nějakou statickou proměnou nějak nastavenou. Takové řešení není, že?

A pokud ne, otázka, má smysl to řešit nějak globálně? Jsem opravdová „lama“, co se nette týče a na nějaký pull requesty se asi moc ještě necítím, ale kdo nic nezkusí, nic nezíská :)

To není řešení, ale nástřel toho, jak by to řešené být mohlo. :) Jazykové mutace to neřeší, protože ten projekt jazykové mutace nikdy mít nebude. :)

To už záleží na Tobě, jak si to nastavíš. Config bude vždy přehlednější, než několik proměnných v presenteru → protože config se dá hezky zanořovat.

A každý modul má vlastní config, takže nic nikde nerozbiješ a nastavuješ jen, když ho programuješ. Takhle vypadá třeba nějaký reálný pro malý modul:

parameters:
    acl:
        Dev:
            - exec

    menu:
        dev:
            presenter: Dev
            title: Dev
            hiddenApp: TRUE
            icon:
                name: linux
                color: orange

services:
    DevPresenter:
        class: \App\DevPresenter
        setup:
            - injectParameters(%tempDir%)

A výsledek pak vidíš v menu nějak takhle http://imgur.com/tK2j9ae.

Hlava napsal(a):

Ale jak říkám – nejedná se pouze o menu.

Však si tam můžeš dát i acl třeba a tam si dopsat akce, které se mají hlídat. V tomhle projektu nechci hlídat všechy, ale jen definované. Ty si pak automaticky generuji do pole checkboxů a ve správě uživatelů si můžeš zaškrtnout, kdo kam může a to ovlivní zobrazení menu. To by pro Tebe mohla být nejlepší cesta.

Editoval Pavel Kravčík (16. 12. 2015 12:32)

Pavel Kravčík napsal(a):

Takhle to určitě asi fungovat může, jen mi to přijde jako řešení už trochu „vedle“ samotného Nette. Potřeba dopsat spoustu věcí, co mi to budou obhospodářovávat. Ale z reakcí cítím, že mi asi nic jiného nezbyde, že přímo v Nette nic není.

Jen dotaz. To píšeš všechno do hlavního configu? nebo máš neon v každém modulu zvlášť? Automaticky se to při spuštění nahraje nebo musím „ručně“?

Tohle jsou už ale otázky zbytečné a obtěžující, je mi jasné, že to už někde jinde dohledám. Každopádně za ušetření času děkuji.

@iguana007: Jasně, tak nastavování uživatelům už probíhá přes DB. To by bylo hloupé kvůli úpravě práv uživatele šahat do kódu.

@Hlava: Každý modul má vlastní config.neon. To jsem dělal kvůli službám, těch je asi 100 a mít je v jednom configu mi přišlo zrůdné. Já ty práva vytvářím společně s containerem automaticky.

Jo, to by určitě mohlo fungovat, ale taky je to postavené „mimo“ Nette, každopádně děkuji za návrh, tušil jsem, že jinak než procházet soubory to nepůjde.

Díky :)