- Page Life Cycle
A: Stages and corresponding events in the life cycle of the ASP.NET page cycle:
• Page Initialization (Page Init)
• View State Loading (LoadViewState)
• Post-Back data processing (LoadPostData)
• Page Loading (Page Load)
• Post-Back Change Notification (RaisePostDataChangedEvent)
• Post-Back Event Handling (RaisePostBackEvent)
• Page Pre Rendering Phase (Page PreRender)
• View State Saving (SaveViewState)
• Page Rendering (Page Render)
• Page Unloading (Page UnLoad)
2. ASP.NET Web server controls, HTML server controls and HTML Intrinsic Controls
A:
ASP.NET Server Controls
• They detect the target browser’s capabilities and render themselves accordingly.
• Processing would be done at the server side. In built functionality to check for few values
(with Validation controls) so no need to choose between scripting language which would be
incompatible with few browsers.
• They have an object model different from the traditional HTML and even provide a set of
properties and methods that can change the look a behavior of the controls.
• They have higher level of abstraction. An output of such control can be the result of many
HTML tags that combine together to produce that control and its events.
• Not much of direct control on these controls as the code is inbuilt.
• They have higher level of abstraction, which increase overhead on server side.
• Migration of ASP to any ASP.NET application is difficult.
3.HTML Server Controls
• They have no mechanism of identifying the capabilities of the client browser.
• They follow the HTML-centric object model.
• The controls can be made to interact with Client side scripting (depends).
• Migration of the ASP project thought not very easy but can be done by adding
runat3server to all HTML tags in ASP.
4.HTML Intrinsic Controls
• Model similar to HTML
• They can directly interact with Client side scripting
• On server side, it’s considered as plain texts only so not much control over it on server
side.
5. Validator controls
A:
• RequiredFieldValidator
• CompareValidator
• RangeValidator
• RegularExpressionValidator
• CustomValidator
All Validator controls require control to validate except CustomValidator. These Controls validate
on server as well as client depending on client browser. For CustomValidator, we need to implement
validation logic on client9server9both.
6. User Controls
A: The ASP.NET server controLs provide a great deaL of functionaLity, but they cannot
cover every situation. Web user controLs enabLe you to easiLy define controLs as you need
them for your appLications, using the same programming techniques that you use to write. The
extension must be .ASCX and they generaLLy don’t have and tags. The LifecycLe
of user controLs is simiLar to page LifecycLe.
The controLs can be Loaded staticaLLy or dynamicaLLy. When a controL is created dynamicaLLy at run
time, some information about the controL is stored in the view state that is rendered with the
page. When the page is posted back to the server, however, non-dynamic controLs (those
defined on the page) are instantiated in the Page.Init event and view state information
is Loaded before the dynamic controLs can be recreated (generaLLy in the Page_Load
handLer). EffectiveLy, before the dynamic controLs are recreated, view state is temporariLy
out of sync with the page’s controLs. After the Page_Load event has run, but before controL event
handLing methods are caLLed, the remaining view state information is Loaded into the
dynamicaLLy created controLs.
In most scenarios, this view state processing modeL works fine. TypicaLLy, you add
dynamic controLs to the end of a container’s coLLection of controLs. The view state information
stored for the dynamic controLs is therefore extra information at the end of the view state
structure for the appropriate container, and the page can ignore it untiL after the controLs are
created.
7. View-State
View state is stored in a hidden fieLd on each ASP.NET page caLLed VIEWSTATE. Each time a page
is posted to itseLf, the contents of the VIEWSTATE fieLd are sent as part of the post. The
primary use of view state is for controLs to retain their state across post-backs. The view state
is packed with the page. So it inevitabLy adds a few extra kiLobytes of data to the payLoad. A
compLex, reaL-worLd page can easiLy find 10KB of extra stuff packed in the HTML code sent to the
browser. It’s composed of pLain text (in base64 format) and it couLd be tampered, so it is not
recommended to store sensitive data in the view state (credit card numbers and passwords etc.)
8. Post-Back
A: Post-Back is a mechanism that enabLe us to do server-side actions. Some actions can be handLed
on the cLient side, meaning they don’t require
anything to be processed on the server side. (For exampLe showing a mouseover
image effect.) On the other hand, sometimes you need to do more compLex things which you cannot do
on the cLient side. (For exampLe, changing a data source on the server side.) Because of this need,
there’s the postback mechanism. The page “posts“ back the page to the server. (As the name impLies,
this is a POST, not a GET). I recommend that you use the foLLowing Link as a starting point to get
more insight how pages are processed and the event modeL;
Inline V/s Code-Behind
A: ASP.NET supports two modes of page deveLopment:
• Page Logic code that is written inside
No comments:
Post a Comment