Jak si mezi moduly předávat informace ke konfiguraci, zobrazení, aktualizace apod
- akadlec
- Člen | 1326
Mám teď appku rozdělenou na jednotlivé moduly (accounts, blog, menu, etc.) a řeším jak si z těchto doplňkových modulů předat info do hlavního systémového modulu, např. že modul se dá konfigurovat.
1. Třeba account module předá info systémovému modulu aby v settings zobrazil možnost nastavení třeba zda se může použít nějaký sociální authenticator, či co vše po uživateli vyžadovat, nebo kam přesměrovat po přihlášení. Vím že by se to dalo řešit přes konfiguraci v neonu ale to je takové moc IT positive řešení, potřebuju aby to bylo pro BFU, admin se logne a bude mít možnost změnit.
Dále kde to uložit? Generovat neon? Nebo jako json do databáze. Ale pak by to zase chtělo aby si to dokázala načíst extension v load metodě šlo by?
Jak zobrazit editační form pro ten daný modul? Vytvořím si form komponentu pro settings daného modulu, to není problém. Eventuelně by se i dala otagovat ale pak by se chtělo k té továrničce nějak v presenteru dostat protože dělat to klasicky předáním továrničky v createComponent metodě by zavádělo závislosti na jednotlivé moduly v systémovém modulu
2. Dá se i nějak řešit update modulu? Dejme tomu že je budu na gitu verzovat, lehce porovnám zda je modul aktuální či ne a nabídnu update. Appka je na composeru, v balíčcích budou i moduly takže jde nějak pro bfu udělat klikací composer update konkrétního balíku? Nezkoušel to už někdo, spustit shell příkaz pro update?
- David Matějka
- Moderator | 6445
1. jak to resim ja:
- ukladani
mam tabulku, setting se sloupecky module, key, value
module je identifikator (viz nize getIdentifier) jednotlivyho
„konfiguracniho modulu“ – treba tedy „account“
- jednotlive konfiguracni moduly jsou registrovany jako sluzby s tagem, konfiguracni modul implementuje interface, zjednodusene:
interface ISettingModule
{
public function getIdentifier();
public function getFormFactory();
}pak je tam nejaky spravce techto modulu, ktery si drzi vsechny registrovane konfiguracni moduly. Presenter si pak z tohoto spravce vytahne jednotlive moduly, vytvori formulare, zobrazi…
2.
Nezkoušel to už někdo, spustit shell příkaz pro update?
nevidim duvod, proc by to nemelo jit…
Editoval matej21 (22. 9. 2014 20:13)
- pepakriz
- Člen | 246
Když už tady bylo zmíněno Venne, doporučuju se raději podívat na tento repozitář: https://github.com/venne/venne . Nejedná se o CMS jako tomu bylo dříve, ale pouze o jakousi administraci, do které je možné pomocí dalších balíčků doplňovat sekce/funkce,… Příklad takového balíčku je například https://github.com/Venne/files pro správu souborů. (Upozorňuji, že je to celé pouze preview)
Osobně jsem od klikacích nástrojů pro instalaci balíčků opustil, protože ve většině případů jsem musel řešit migrace db na míru a proto tlačítko „(od)instalovat modul“ ve většině případů nefungovalo. Nyní používám jen takový pomocný nástroj venne/packages, který po instalaci pomocí composeru zaregistruje balíček do systému.
- akadlec
- Člen | 1326
Jo jako bez klikačky bych se asi taky obešel, jen sem nad ní uvažoval že by byla fajn pro zjednodušení ;)
Asi to tedy pořeším přes nějakou service do které se budou jednotlivé moduly hlásit.
Jen tedy jak ten config? Je nějaká možnost aby se to dalo pořešit loadConfiguration ?
- pepakriz
- Člen | 246
Jestli chceš mít pro každý modul nějaký editační form, udělal bych si na to nějakou službu, kam mi balíčky budou registrovat své formy – pomocí compilerExtension.
Konfiguraci balíčku/modulu ukládej klasicky do neonu a používej v compilerExtension. Jestli potřebuješ, aby se nějaká služba generovala podle nastavení v db, musíš si napsat nějakou factory, která na základě db sestaví a nakonfiguruje službu.
- akadlec
- Člen | 1326
Jasný, formy není problém, to bude mít každý modul u sebe svou továrničku a ty bych asi získával přes tu službu co bude moduly sdružovat do které by to každý modul dával přes zmíněnou compilerExtension to není problém.
Nad tím neonem jsem právě uvažoval zda je to ok ukládat takovýto config do filesystému, ale zase mi to pak přijde snadnější k získání. Chtěl bych tu konfiguraci mít ve stylu user defined – extension defined – extension default. Takhle jsem to měl na projektu předtím s tím že jsem to měl v db což jsem neměl problém protože sem to řešil přes konfugurační službu ale nebylo to moc čisté ;)
- akadlec
- Člen | 1326
Další věc co mě napadá. Jde nějak rozumně rozdělit front, admin, api etc.? resp když už to jde na presentery tak to samo vím, ale co to zjistit nějak v compilerExtension?
Představa je taková že mám nějakou službu co mě zpracovává statické soubory (js, css). V ext mám definovanou metodu getStaticFiles co mě je vrátí, ale vrací je kompletně jak pro front a pro admin. Lepší by bylo kdybych už v té ext věděl že jsem v adminu.
- David Matějka
- Moderator | 6445
ne, z pohledu nette to nejde – generovany kontejner je spolecnej pro vsechny moduly a routovani probiha az po vytvoreni kontejneru. Musel by sis to vyresit sam (oddelit kontejnery v bootstrapu, testovat, zda URL obsahuje „admin“ atd)
Ja tohle ve svych aplikacich taky nemam poradne doreseny, ale mel jsem takovouhle predstavu: complier extension by poskytoval „balicky“ bez ohledu na to, jestli je to front, admin. a ja bych v konkretnim modulu (nebo treba v neonu pri konfigurovani webloaderu) vyjmenoval balicky, co chci pouzivat.
Tuhle predstavu jsem zavrhnul a nahradni jeste nemam domyslenou. Ale ma v tom figurovat bower, grunt a neon :)