Portál AbcLinuxu, 21. července 2025 16:56
JSF umožňuje nastavit u pravidla navigace element <redirect />. Manuály zmiňují, že se to hodí v případě, že volání provádí např. zápis do databáze (redirect se provede až při zobrazování následující stránky), takže pokud uživatel stiskne F5, neprovede se zápis dvojmo. Užitečné to také může být, pokud chcete, aby bylo možné na výslednou stránku vytvořit bookmark - URL v adresním řádku skutečně vede na zobrazenou stránku (a ne na předchozí). Samostatnou kapitolou je autorizace - ověřování přístupu k jednotlivým stránkám (o tom možná někdy příště).
Co ovšem příručky nezdůrazňují (a mě nenapadlo) - pokud se použije redirect, jedná se o nový request, který neobsahuje předávané parametry. Takže jsem strávil půlden hloubáním nad skutečností, že se mi prostě neinicializují parametry pro výslednou stránku. Výsledně tak lze redirect použít pouze v případě, že zobrazovaná stránka nezávisí na stránce předchozí.
Tiskni
Sdílej:
Ano, tahám parametry z requestu (no dobře, nejen).
Typicky to používám v situaci, kdy zobrazím dataTable s položkami a ke každé řádce dám commandLink, který odkazuje například na stránku s detailem. Pokud znáte/používáte lepší způsob, rád se nechám poučit.
Máte pravdu v tom, že se všechny backing beans naplní před redirectem (a akce se provedou také před tím). Jenže pokud následující stránka využívá bean, která je v request scope, provede se po redirectu její inicializace znovu (a k tomu právě chybí parametry). Jak jsem naznačil v předchozí větě, značnou část backing beans mám v request scope, cpát všechno bezhlavě do session mi nepřipadá jako úplně dobrý nápad.
pouzivamPokud znáte/používáte lepší způsob, rád se nechám poučit.
<t:updateActionListener property="#{backingBean.currentId}" value="#{item.id}" /> z Tomahawku (pouzivam kompletne implementaci od Apache). na netu se daji najit nejake priklady pouziti.
To urcite ne, ale tak nejak sem zatim neprysel na moc situaci, kde muzu mit data jenom v request scope. Mozna tvorim trosku specificke stranky, ale v podstate BB pouzivam z 90% na formulare a ten proste nemuze byt jenom v requestu (nebo nevim jak, protoze chci aby fungovali takove ty veci jako validace, znovuzobrazeni formulare se "spatnymi vstupy", atd...)Jak jsem naznačil v předchozí větě, značnou část backing beans mám v request scope, cpát všechno bezhlavě do session mi nepřipadá jako úplně dobrý nápad.
Díky za tip, určitě se na to podívám. Zatím se ale snažím využívat Tomahawk co nejméně a držet se standardu.
Co se request scope týče - tentokrát nevidím problém já - používám request BB také pro formuláře a vše (validace, znovuzobrazení) bez problémů funguje. (Ostatně, hledal jsem nějaká doporučení ohledně scope a našel jsem cosi ve smyslu "BB jsou obvykle managed && v request scope" - ale věřím, že je možné podobně snadno nalézt protipříklad :)
Nicméně mám pocit, že jsme se vzdálili od původního tématu - po redirectu se request BB prostě zahodí a vytvoří znovu (bez inicializace). To byl problém, na který jsem chtěl upozornit.
Nicméně mám pocit, že jsme se vzdálili od původního tématu... i presto si dovolim jeste jednu poznamecku
že je možné podobně snadno nalézt protipříklad :)moje BB vypadaji tak ze funguji jednak jako DAO, druhak jako ukazatel na vybrany prvek se kterym se soucasne pracuje - a potrebuju ho mit v pameti po celou dobu dokud se ho nerozhodnu ulozit zpet do databaze - tohle bych asi v requestu neudelal, ne? (nebo se mylim a muzu si jit cist zaklady jsp
)
Beze všehoNicméně mám pocit, že jsme se vzdálili od původního tématu... i presto si dovolim jeste jednu poznamecku
moje BB vypadaji tak ze funguji jednak jako DAO, druhak jako ukazatel na vybrany prvek se kterym se soucasne pracuje - a potrebuju ho mit v pameti po celou dobu dokud se ho nerozhodnu ulozit zpet do databaze - tohle bych asi v requestu neudelal, ne? (nebo se mylim a muzu si jit cist zaklady jspMyslím, že přesně k tomu by měla sloužit kombinace request BB a t:UISaveState, nicméně ještě jsem neměl potřebu toto řešit. Tedy - nevím, jestli si úplně rozumíme, teď mám na mysli posloupnost formulářů s "hromadným" uložením na závěr. Pokud by se jednalo o jeden formulář, vystačím samozřejmě pouze s request BB.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.