prosím o radu s použitím persistentního parametru

Nevidím na tom návrhu nic špatného. Persistentní parametr můžeš nastavit na NULL nebo ho můžeš ignorovat pokud ti nevadí v URL.

Zamezit tak, že ho buď nepoužiješ v action a render metodě nebo pokud ho používáš v nějaké beforeRender, startup, … zjistit na jakou akci jde požadavek a ošetřit/NULLovat.

Možná bych ten presenter rozdělil na dva (více). Chápu to tak, že ten parametr skutečně je persistentní, pokud jde o zpracování kampaně. Administrace a vytváření nové kampaně jde pak ale trochu mimo a asi bych ten kód oddělil.

Pokud však častěji dochází ke změně kampaně, pak ten parametr persistentní není a bylo by lepší si ho předávat ručně. Tohle už je trochu filosofie návrhu aplikace, to rozhodnutí je na tobě.

Jak to chápu já:

1. Pokud to funguje trochu jako stavový automat, kde si načteš kampaň a pak jsi celou dobu ve stavu „přihlášené kampaně“ a všechny operace se týkají jen jí, tak bych persistentní parametr použil a všechno, co je mimo tento stavový automat oddělil.
2. Pokud je běžné vytvořit jednu kampaň, pak upravit jinou a pak úplně jinou smazat, pak to neprochází žádnými stavy, tedy nepoužiješ persistentní parametr a parametry budeš předávat ručně.

Šaman napsal(a):

Možná bych ten presenter rozdělil na dva (více). Chápu to tak, že ten parametr skutečně je persistentní, pokud jde o zpracování kampaně. Administrace a vytváření nové kampaně jde pak ale trochu mimo a asi bych ten kód oddělil.

Pokud však častěji dochází ke změně kampaně, pak ten parametr persistentní není a bylo by lepší si ho předávat ručně. Tohle už je trochu filosofie návrhu aplikace, to rozhodnutí je na tobě.

Jak to chápu já:

1. Pokud to funguje trochu jako stavový automat, kde si načteš kampaň a pak jsi celou dobu ve stavu „přihlášené kampaně“ a všechny operace se týkají jen jí, tak bych persistentní parametr použil a všechno, co je mimo tento stavový automat oddělil.
2. Pokud je běžné vytvořit jednu kampaň, pak upravit jinou a pak úplně jinou smazat, pak to neprochází žádnými stavy, tedy nepoužiješ persistentní parametr a parametry budeš předávat ručně.

Jo, právěže jsem koketoval s myšlenkou zda to rozdělit na dva presentery, ale raději jsem se nejprve chtěl zeptat na názory zkušenějších, zda se to běžně neřeší nějak jednodušeji.

Každopádně děkuji všem za odpovědi.

Šaman napsal(a):

Ber perzistentní parametr jako uložení stavu. Buď globálního stavu celé aplikace (třeba zvolený jazyk), nebo nějakého stavového automatu (typicky komponenta, ale klidně presenter). Ale správně navržený automat by zas neměl dělat jiné, nestavové věci, proto se nabízí presenter rozdělit, nebo tu stavovou část vyčlenit třeba do komponenty.

Naopak, co by persistentní parametr být neměl, je „defaultně nastavená proměnná“. Ale hranice mezi stavem a proměnnou je poměrně tenká a záleží i trochu na pocitu v tom kterém případě.

Tzn. persistentní parametr je něco jako session proměnná?

Já to u sebe nevidím na stavový automat. Spíš jsem si chtěl malinko ulehčit práci s tím předáváním parametru ID, pro akce a views, ve kterých ho vždy potřebuju. Ale sám cítím, že by to nebylo ono, takže si to budu předávat ručně. Každopádně presenter jsem rozdělil na dva, vyvořil jsem komponentu na create/edit formulář a nechám to tak, je to o dost přehlednější.

Persistentní parametr se objeví v adrese, tak je vhodný v případech, kdy má adresa reflektovat nějaký stav. Tedy pokud má mít uživatel možnost poslat odkaz na tento stav někomu dalšímu.
Anebo pokud potřebuješ mít adresu jinou pro různé verze obsahu kvůli SEO, což je zrovna případ toho jazyka. Pohodlnější pro programátora i uživatele by bylo pamatovat si jazyk v session, ale nechceme, aby vyhledávače našly na stejné adrese různé jazykové verze.

Session je druhá možnost uložení stavu, ale ta je pro každého uživatele unikátní a nedá se nijak poslat. Třeba nákupní košík. Vlastně jakýkoliv eshop s online objednávkami je tak trochu stavový automat, ale místo persistentních parametrů používá třeba session. Když promažeš cookies (tedy i session id), tak po přihlášení začínáš u mnoha online serverů zase od začátku, zvlášť u těch, kde se nepřihlašuješ.

No a třetí možnost je samozřejmě uložení stavu v databázi, což je ideální použít když se přihlašuješ. Očekáváš, že když se odhlásíš a přihlásíš na jiném počítači, tak třeba košík budeš mít stejný.