On 11/8/06, David Geary <[EMAIL PROTECTED]> wrote:
2006/11/8, Craig McClanahan <[EMAIL PROTECTED]>: > > On 11/8/06, Ramineni Viswanath <[EMAIL PROTECTED]> wrote: > > > > While on a page, I call the same page with a different > > set of query parameters, it is being treated as a > > postback. > > > > For example my current url is > > > > /mainmenu.faces?menuid=0 > > > > I have a HtmlOutputLink on this page with the value > > set to /mainmenu.faces?menuid=26. When I click on this > > link, isPostBack() is showing "true". Is this the > > correct and intended behaviour? > > > The mechanism used to declare a request being a postback is whether the > ViewController.restoreView() method provided by JSF determines that there > was an existing view that could be restored. In turn, if you are using > server side state saving with current 1.1 implementations, this decision > is > based solely on the view identifier, not on any related parameters. Thus, > if you are using server side state saving, JSF will treat your two URLs as > being the same, and will restore the previous state (and, therefore, the > postback property will be set to true). > > If you were to use client side state saving, on the other hand, the two > URLs > would be considered distinct views (since the HtmlOutputLink ends up doing > a > GET to the second URL), with no state to be restored, and therefore > postback > would be false. Holy cow, I didn't know that. Is that not a bug according the definition of a postback? IMO, behaviour that differs depending upon state-saving mode is bad news.
The key issue is the definition of a URL, which does *not* include query parameters. It's not just JSF that treats these things as the same; so does HTTP. Think about caches, security constraints, search engines ... all are based on the assumption that two matching URLs are referencing the same resource. The right design architecture, if you want these two URLs to be treated as different pages, is to make them different URLs. david Craig --Vish
> > > Craig > >
