Portál AbcLinuxu, 21. července 2025 17:00
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.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.