-
WSS Navigation Component
Several standard controls are included with default.master that provide the basic infrastructure for navigation. For example, the ASP.NET SiteMapPath control that has been positioned at the very top of the page populates a breadcrumb navigation menu that allows users to navigate from the current site upward to the parent site and all the way to the top-level site of the current site collection.
<p> Navigation in WSS is based on the navigation-provider infrastructure introduced in ASP.NET 2.0. In this model, a navigation provider is designed and created to provide a set of navigation nodes. In many cases, the nodes supplied by a navigation provider can be bound to a <b>menu control</b> or a <b>treeview</b> to give users a user interface component with which to navigate around the site. </p> -
Web Part Pages
Before diving into the details of how Web Part pages work, two important aspects of their architecture must be noted. First, support for customizing and personalizing Web Parts is available in site pages but not in application pages, thus giving site pages a clear design advantage over application pages.
<p> Second, adding and customizing Web Parts does not require customizing the Web Part pages that host them. A Web Part page defines Web Part zones but does not define what goes inside these zones. Instead, all of the data for tracking Web Part instances and their customization and personalization data are kept in separate tables inside the content database. This means that a Web Part page can remain in a ghosted state even though users are continually adding, customizing, and personalizing the Web Parts within its zone. </p> -
User control in wss3
It is important to understand that WSS does not support user customization of user controls. User controls are always loaded from the file system of the front-end Web server and compiled into assembly DLLs. Furthermore, user controls can be copied to the front-end Web server only by someone with farm-level administrative privileges. For these reasons, you can assume that you can always write in-line code in an .ascx file.
-
Safe Mode Processing
Ghosted site page and application page can containe inline code, it is basically traditional aspx page. But all customized(unghosted) site pages are parsed and processed in a special mode known as safe mode. The primary motivation for safe mode involves the fact that standard users can modify the contents of site pages. In other words, a user(such as a site owner) processing no administrator privileges within the farm can make any modifications to a page within a site. Consider a scenario in a large farm in which a site administrator attempts to mount an attack on the Web server by writing C# code within a customized site page inside an in-line script block. Safe mode prevents this type of attack by disallowing in-line script in any customized source. So if your site pages is an instance of page template which has inline code, the site page will break if you modify the site page in the site unless you do something to prevent this happening. For this reason, you should advoid adding in-line script to page templates. If you want o allow in-line scripts to run in unghosted site pages, you can accomplishe this by adding the following PageParserPath element within the SharePoint section of the web.config file.
-
Non compile mode in sharepoint
In wss3, cutomized pages are not processed by using the standard ASP.NET mode in which a page is compiled into an assembly, instead, customized pages are parsed by the ASP.NET page parser and then processed using the no-compiled mode feature that was instoduced with asp.net 2.0.