An easily navigable web site is half of the battle. I wouldn’t write about the revolutionary navigation designs and ideas here, let the web designers struggle with that. In this post, only cool and standard developer navigation will be considered. So let’s begin!
Our syllabus states the following on this objective: when to extend site map provider, treeview menu vs. site map path, programmatically manipulating site map nodes, overriding menu rendering by controls adapters, filtering site map nodes based on user roles. A nice collection.
The foundation of ASP.NET site navigation is the SiteMap. Now there are some classes with this name, so let’s lay out a terminology. The SiteMap is the XML document from where the data originates. It populates the SiteMapDataSource data source object, which looks for the web.sitemap file to get its data. It also populates the SiteMapPath control, which is a graphical representation of the sitemap, and is also known as breadcrumbs. I never understand why do they call it that way, but I have no English background.
So what’s the big deal with the epic battle between SiteMapPath and TreeView? The secret is that TreeView actually uses the SiteMapDataSource control to gain its data, so it reflects any changes made in the SiteMapDataSource. However, SiteMapPath queries the underlying web.sitemap file, without the intervention of a datasource object, so changes made in the SiteMapDataSource won’t affect it.
A little info about web.sitemap: it must be placed in the root directory, must have a root element, but you can define sub sitemaps inside elements. So the following XML is valid:
ASP.NET introduces an event-handling method similar to client applications like a WPF or WF application. The main different between the classic event-handling and ASP.NET’s event-handling procedure is that in ASP.NET, a server is involved. Events are triggered in the browser, which needs to communicate them to the server. Sometimes you got to remember yourself to this fact when dealing with events.
ASP.NET server controls have a large number of predefined events, and event handling code uses the traditional .NET signature, an object, which is the sender of the event, and any event-specific information wrapped in an EventArgs class.
To understand how and when you can handle events, let’s take a look at the page events of ASP.NET:
|PreInit||This event fires first when a page is being requested. You should add dynamically created controls here, or set the master page/style them programmatically here.|
|Init||Occurs when the page is initialized. The controls are initialized, but their properties don’t.|
|Load||The properties of the page are loaded back from the ViewState (or built up, if not a postback).|
|Validate||Not an event you can respond, validation of controls occurs here.|
|Event Handling||The events of the controls on the page are fired.|
|Render||Page render is running.|
To help you memorize this pattern, use SILVER as your keyword.
I'm a software developer professionalizing in the .NET platform and iOs development. Here you can find my notes for Microsoft certifications.
Everyone who seeks, finds
- .NET (35)
- .NET 70-536 (35)
- Configuration, Diagnostic, Management and Installation Features (6)
- Globalization, Drawing and Text Manipulation (2)
- Improving the Security of a .NET Framework Application (5)
- Interoperability, Reflection and Mailing Functionality (3)
- Serialization and IO Functionality (7)
- Service Processes, Threading and Application Domains (2)
- System Types and Collections (6)
- .NET 70-536 (35)
- ADO.NET (24)
- ASP.NET (68)
- Application Architecture (1)
- ASP.NET 70-562 (44)
- PRO ASP.NET 70-564 (20)
- Design Patterns (10)
- Objective-C (4)
- Personal (4)
- Silverlight (6)
- SQL Server (43)
- 70-433 (27)
- 70-451 (16)
- WCF (8)
- Windows Azure (8)
- WPF (20)