Záludnost použití <redirect /> v pravidlech navigace

8.2.2006 08:29 | JSF

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í.

       

Komentáře

[Leoš Literák]

Provede se skutecne response.sendRedirect(), takze prohlizec posle novy request? A jak se vlastne urcuje, na ktere URL se to ma presmerovat? Ja videl jen nejake priklady faces-config.xml a z nich mi to nebylo jasne.

[PRYB]

Předpokládám že ano - první request směřuje na URL aktuální stránky (tj. té, na které jsem klepnul na tlačítko). Teprve server rozhodne (pomocí faces-config a případně pomocí navázané akce), kterou stránku zobrazí. Tj. bez redirect je v adresním řádku obvykle nesprávná adresa. Pokud je <redirect /> nastaveno, objeví se správná adresa - tj. prohlížeč to musel dostat na vědomí. Přesměrování se provádí až po provedení akce a vyhodnocení navigace - v tu dobu už je jasné, na které URL přesměrovat.

[Jiří (BoodOk) Kadeřávek]

Takže jsem strávil půlden hloubáním nad skutečností, že se mi prostě neinicializují parametry pro výslednou stránku.

To je presne duvod proc tyto frameworky nemam rad. Misto, aby si clovek hral se zaludnosti aplikace, trapi se zaludnostmi frameworku. No flame, pls, ted nijak neutocim na JSF.

[Leoš Literák]

I proto ma abicko vlastni "framework", ktery dela presne to, co chci ja a kdy to chci ja.

[Jiří (BoodOk) Kadeřávek]

Potvrzujes svatou pravdu, ze nejlepsi framework je vlastni framework.

[PRYB]

Ano, ovšem dobře navrhnout vlastní (nejlépe obecný) framework není jednoduché a napsat ho je dost práce - s tím už mám určitou zkušenost. Standardní framework má právě tu výhodu, že je standardní, že ho udržuje někdo jiný a že je výrazně jednodušší sehnat někoho, kdo s ním umí. To se samozřejmě netýká pouze JSF.
Každopádně se tu objeví více zápisů, ke kterým se takovéto komentáře budou hodit :)

[Martin Beránek]

souhlasim s tim ze JSF bych pro Abicko nepouzil, ale jak tak postupne studuji Tapestry, tak to vypada velmi slibne.

JSF je podle me vhodne spise pro intranet, protoze optimalizace stranky jde naprosto stranou. na druhou stranu JSF komponenty nejsou jenom komponenty pro Web - takze mnohem sirsi pouziti (viz intranetove aplikce v XUL)

[Martin Beránek]

timto snad chcete rict, ze pouzivate JSF a pritom tahate parametry z requestu? to se muzete vratit spatky k PHP...

redirect neznam, ale predpokladam (a byla by blbost kdyby to tak nebylo) ze vsechny akce (at uz akce jako takove, nebo action listenery) se provedou jeste pred redirektem a stejne tak se pred nim provede i naplneni backingbeanu - tedy nechapu kde je problem s predavanim hodnot

v JSF se do requestu dava jen velmi malo veci (schvalne kolik backingbeanu mate v scope=request ?)

[Leoš Literák]

U nas ve firme se snazime prevest vsechny post stranky na get requesty. POST only design ma spoustu nevyhod, napriklad stranky se nedaji bookmarkovat nebo pri zmacknuti tlacitka back se objevi osklivy dialog, zda chcete opet odeslat formular.

[PRYB]

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.

[Martin Beránek]

Pokud znáte/používáte lepší způsob, rád se nechám poučit.

pouzivam <t:updateActionListener property="#{backingBean.currentId}" value="#{item.id}" /> z Tomahawku (pouzivam kompletne implementaci od Apache). na netu se daji najit nejake priklady pouziti.

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.

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...)

[PRYB]

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.

[Martin Beránek]

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 )

[PRYB]

Nicméně mám pocit, že jsme se vzdálili od původního tématu

... i presto si dovolim jeste jednu poznamecku

Beze všeho

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 )

Myslí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.