Page Switching: Simulating a Nonpostback Experience ASP.NET

Widgets load on page in three ways:

• The very first time they are created;they have no state at this stage

• When a user revisits the page; they load in nonpostback mode and restore their state from persisted state data

• During asynchronous postback; they load in postback mode and restore their state from both ViewState and persisted states

Normally,on a regular visit to the page(i.e.,non pos tback,second scenario) wid gets load their settings from their persisted state and render the UI for the first time.Up on post back,wid gets don’t always restore settings from persisted state and instead update the state or reflect small changes on the UI.For example,when you click the Next button on the Flickr photo widget, it’s a postback experience for thewid get.It does not go and fetch Flickr photos again, it just updates the current page index in its View State.So, it’s important for wid gets to know when they are being rendered for the first time or when it is a postback.

The definition of non post back and post back is different when you have multiple tabs on one page.When you click on another tab, it’s a regular asynchronous post back for ASP.NET because a Link Button gets clicked inside an U pdate Panel.This makes the tab’s Up date Panel post back asynchr onously, and on the server side you can see which tab is clicked.You can then load the widgets on the newly selected tab.But when widgets load, they call Page .IsPost Back, and they get true.So, widgets assume they are already on the screen and try to do a partial rendering or access their own View State. But this is not the case because they are not rendered yet and there’s no ViewState As a result,the widgets behave abnormally and any ViewState access fails.

So,we need to make sure that during the tab switch, even though it’s a regular ASP.NET post back, the widgets don’t see it as post back.The idea is to inform wid gets whether it is a regular visit or a postback via the IWid get Host interface.

On Default.aspx, the SetupWidgets function creates the WidgetContainer and loads the widgets. Here’s how it works:

private void SetupWidgets(Func<WidgetInstance, bool> isWidgetFirstLoad)

The public property IsFirstLoad is determined by what calls the SetupWidget and when. Set up Widget’s job is to render the widgets on the page. So, it gets called during the first visit and subsequent postbacks.The caller knows whether it’s postback or not and can pass a predicate,which decides the value of the IsFirst Load property. WidgetContainer just passes the value of the property to its contained widget via the IWidget Host interface.

So,why not just send true when it’s post back and false when it not and declare the function as Set up Wid gets(bool)?

When a new wid get is added on the page, it is a first-time loading experience for the newly added widget, but it’s a regular post back for existing wid gets already on thepage.If true or false is passed for all widgets, then the newly added widget will see it as a post back just like all other existing wid gets on the page and thus fail to load properly.To make sure it’s a nonpostback experience for only the newly added widget,and a postback experience for existing widgets already on the page, use this predicate feature:

Here the predicate will return true for the newly added widget, but false for any other widget. As a result, the newly added widget get IsFirstLoad = true,where existing widgets get IsFirstLoad = false.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

ASP.NET Topics