Parametry v parameters nebo extension?
- Jiří Nápravník
- Člen | 710
Chci mit v configu nastavitelné některé parametry. Například adresář pro nahrávání fotek, atd. Jak to nejlépe řešit?
Já to nyní dávám do parameters v configu a pak mam Settings třídu, která mi to vytáhne z kontejneru.
Ale nejde to řešit nějak rozumně? Napadá mě třeba mít to v compilerExtension (kterých mám několik modulárně), ale stejně bych tam musel mít nějakou „přepravku“ z které si to vytáhnu.
Jak to řešit nejléle?
- David Matějka
- Moderator | 6445
proc prepravku? proste tu hodnotu predas sluzbe, ktera to potrebuje.
Jestli chces delat nejakou prepravku pro konfiguraci (treba kdyz je tech parametru vic a/nebo na nich zavisi vic sluzeb), tak jedine nejakou konkretni pro to urcite pouziti (tedy s konkretnimi gettery/settery) jako je to treba v doctrine nebo kdyby/facebook
- Jiří Nápravník
- Člen | 710
Protože někdy je využíván parametr více službami a přijde mi lepší zavolat si nějakou třeba PhotoSettings, než v té dané extensioně vypsat více služeb a přidávat přes settery.
Řekněme, že mám třeba u těch fotek adresář a rozměry na které ořezávat fotku. Takže myslíš, že v tomhle případě pokud to budu chtít využívat na více místech, tak udělat přepravku? Pokud na jednom tak rovnou si nastavit v té službě/formfactory apod?
A když nějakou přepravku, tak to udělat spíše jako PhotoSettings a bude tam všechna konfigurace pro modul Photo, nebo udělat přepravku pro tu directory a pak zase pro ty rozmery?
A nějaké základní nastavení jako název aplikace, doména, mail apod. Tam my prijde asi nejlepší udělat nějakou obálku nad tím…
- Oli
- Člen | 1215
Mám to přesně jak píšeš @JiříNápravník. Každej modul má svoji přepravku. Každej modul je totiž jedna extension, takže se zaregistruje buď vše nebo nic. V „sandboxu“ je potom AppSettings, kde jsou informace jako název, mail, jazyky, … to mě funguje dobře. Není to ideální, ale každej modul si drží seznam parametrů a spravuje si přepravku, takže by s tím snad neměl být problém (přesunem do jiného projektu přesunu i parametry)
- castamir
- Člen | 629
Kde ty parametry reálně používáte? Pokud v komponentě nebo modelové třídě, pak si tyto hodnoty předejte přes konstruktor nebo setter (setup v konfiguraci). Budete nad tim mít docela dobrou kontrolu.
Pokud tyto hodnoty používáte v presenteru, tak doporučuju zvážit, zda vaše presentery nedělají víc, než je potřeba resp. zda nepřesunout logiku z presenteru právě do modelu a popř. i osamostatnit komponenty. Tím se dostanete k řešení výše.
Něco jako obecná přepravka na parametry asi nebude ideální. Aby taková přepravka měla reálné použití, musela by mít nějaké pevné rozhraní, tj museli byste omezit rozsah atributů, které může získat a to např. právě přes settery, ale to už je ta samá práce jako při nastavení přímo do služeb či komponenty, ne?
Editoval castamir (2. 12. 2015 14:49)
- Jiří Nápravník
- Člen | 710
Používám je v modelovych tridach a komponentach. V presenterech jenom zakladni AppSettings (kde je nazev projektu apod).
Já nemám úplně obecnou tu přepravku, je to přepravka na ten daný modul.
Konkrétní příklad. UserModule má parametr, kam nahrávat avatar, a jaké velikost. Potom to potřebuji v komponentě pro registraci, úpravy registrace, generátor velikostí obrázku, latte filtr a pak v samotné modelové fasáde.
Pokud si v extension vytvořím tu přepravku, tak si to vše nastavím, a pak si vyžádám tu jednu přepravku v těch pěti třídách. Pokud přepravku ne, ale vše definovat přímo, tak budu pětkrát psát to samé pro každou službu/komponentu. Což mi přijde trochu kontraproduktivní…
- Jiří Nápravník
- Člen | 710
Něco typu ImageManager s metodama uploadImage, getImageWithSize, …
dava to smysl a treba u toho uploadu. Ale potrebuji na nekolika mistech ziskat ty velikosti pres getter, ci-li pak by se z toho stejne stala v podstate prepravka s metodou navic uploadImage… Samozrejme je mozny udelat, zase dalsi sluzbu, ktera ponese ty vleikosti, ale pak mi bude bobtnat celke mdost zavilosti dle me.
Na co potřebuje latte filtr cestu ke složce?
filtr avatar prijima uzivatele, pokud je avatar v pohode dostane ho, pokud ne dostane systemovy, ktery je nastaven v konfigu
A taky me jeste napada, co kdyz to budu chtit upravovat pres databazi tahle nastaveni. To pak podle me neni resitelne na urovni compilerExtension ne? A tam pak asi dava smysl mit tu prepravku, ktera se podiva do dtb a pokud nic neni tak pouzije tu defaultni.