• Choose a category
• All
• Classic-Fiction

By Root 5440 0

class that .ascx user controls inherit by default. The default class is System.Web.UI.UserControl. The new class name must include assembly information.

validateRequest

Indicates that ASP.NET examines all input from the browser for potentially dangerous data. It’s set to true by default.

viewStateEncryptionMode

Indicates the encryption mode of the view state. Feasible values are Always, Never, or Auto. Auto means that the view state is encrypted only if a control requests it.

In particular, the pageBaseType attribute is an extremely powerful setting you might want to leverage when all your application pages inherit from a common code-behind class. In this case, instead of modifying all the pages, you centralize the setting in the web.config file at the level (machine, application, or subdirectory) you want.

An interesting attribute is maxPageStateFieldLength. One of the problems developers might experience with a too-large view state is that some legacy firewalls and proxy servers might not be capable of carrying all those bytes back and forth for a single input field. As a result, the content of the view state is truncated and the application fails. This is particularly likely to happen on pretty simple Web browsers, such as those you find in palmtops and smartphones. If the real size of the view state exceeds the upper limit set through the maxPageStateFieldLength attribute, ASP.NET automatically cuts the view state into chunks and sends it down using multiple hidden fields. For example, if you set maxPageStateFieldLength to 5, here’s what the page contains:

...

The final byte count of the client page is even a bit higher than in the default case, but at least your page won’t fail because of a truncated view state on simple and not too powerful Web browsers.

A sign of the evolution of the Web platform is the clientIDMode attribute introduced in ASP.NET 4. Earlier versions of ASP.NET use a built-in algorithm to generate the client ID values for HTML elements output by server controls. The algorithm guarantees uniqueness but do not necessarily result in predictable IDs. Until the advent of AJAX, that has never been a problem. AJAX brought developers to write more client-side code and subsequently raised the need for accessing in a reliable and easy way any DOM element added by ASP.NET controls. The clientIDMode attribute offers two main options: using static IDs (and thus accepting the potential risk of having duplicates) and using predictable IDs. A predictable ID is essentially an ID generated by ASP.NET but through a much simpler algorithm that doesn’t walk through the entire list of naming containers like the default algorithm we used for years.

The section contains a bunch of child sections, as shown here:

...

...

...

...

The and sections define a collection of @Register and @Import directives to be implicitly added to any page. The section, instead, plays the role of remapping an existing control type to another type specified in the markup:

tagType=

"System.Web.UI.WebControls.TextBox"

mappedTagType=

"Samples.MyTextBox" />

As an example, you can use this tag to automatically invoke a TextBox of yours wherever the source code invokes, instead, the standard TextBox control out of the markup.

Finally, defines a collection of elements that identify the device-specific content that ASP.NET should ignore when it displays a page. Device-specific content is listed through a child element. The usefulness of this feature is illustrated by the following example. Suppose you have the following