The navigation results could be considered a repository of navigational links used on a page, or accross a project, allowing the assignment of symbolic names to such links. For this the two important attributes are the id and path. The id would be unique globally, and could be used to refer to the URL destinations.

Some frameworks include navigational rules configurations, which could be used to determine destination paths based on page of origin (from page), the preceding action or its result.

This could also be used document page flow.

dWebSpec navigation-path descriptor is designed to capture all these possibilities as well as access security roles and ?request options.

Since dWebSpec captures what you are trying to do, irrespective of how you do, such concepts could represented in the specification. However, their implementation would be through custom code.

An example of navigational rules involves using a handler {bb_Button1_Click} that would generate a result that indicates whether the current user is a first time user or an existing user.

The next page to navigate to depends on whether this is a first time user, or existing user, as entered in the table below.

This would need to be implemented in code, as shown in the code segment below.

void Button1_Click(Object Src, EventArgs E) {
  String OutCome = doBusinessMethod();
  if (OutCome.equals("new") {
     Server.Transfer("Registration.aspx", True);
  } else if (OutCome.equals("existing") {
     Response.Redirect("Customer.aspx");
  }

}

We use the sample code to illustrate the fact that these descriptor entries could be implemented easily with custom code.

ASP.NET provides declarative means of implementing some aspects of the navigation-path descriptor. These areas are:

• SiteMap
• Security

Security

The security specification allows the depiction of principals or roles that are allowed to access a particular URL. A specification could appear as shown below, to allow the admin and operator roles access to the invoice page.

ASP.NET provides declarative means of implementing this specification.

The security specifications could be entered in the following ways:

The implementation of these is illustrated as follows.

It is the UrlAuthorizationModule that handles the security authorization. The authorization rules are represented in the <authorization> element in the form of <allow> and <deny> child elements.

The example specification shown at the start of the section is repeated below.

The implementation is as shown below.

  <authorization>
     <allow roles="admin,operator" />
  </authorization>

Instead of roles specification, users could be specified.

The authorization for specific users would appear as shown below.

<allow users="david,henry" />

This configuration would be contained in the Web.config file. This configuration file would be located on the root level; example of a complete file is shown below.

<?xml version="1.0"?>
 <configuration>
       <system.web>
			<authorization>
      	    	<allow roles="admin,operator" />
			</authorization>
     	</system.web>
 </configuration> 

This authorization setting would apply to all of the ASP.NET resources in the root directory and its subdirectories (except overridden by another Web.config file in a sub-folder). We shall get to the overriding shortly.

The implementation provided above is just used as a starting point. It is not page related; it is a general authentication policy for the folder and sub-folders, as indicated above. We have satisfied the following specification.

We now represent again below, a security specification for a page, and one for the site.

The implementation for the site and page security is shown below.

  <?xml version="1.0"?>
     <configuration>
            <system.web>
                   <authorization>
                          <deny users="?" />
                   </authorization>
            </system.web>
            <location path="Invoice.aspx">
                   <system.web>
                          <authorization>
                                 <allow roles="admin,operator" />
                          </authorization>
                   </system.web>
            </location>
     </configuration>
    

Specification for sub-folders follow the same exact scheme, with the Web.config file placed in the sub-folder that is the starting point of that overriding specification.

SiteMap

Another area for which the descriptor could lead to declarative implementation is the SiteMap. This takes advantage of the capture of where to navigate to from a page, associating URL with caption or description. An example is shown below.

Assuming that the current page carrying the specification is “default.aspx” (! Refers to the current page), the SiteMap entry would be as shown below.

<?xml version="1.0" encoding="utf-8" ?>
 
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
 
    <siteMapNode url="default.aspx" title="Home">
        <siteMapNode url="approver.aspx" title="Approver Expenses" />
        <siteMapNode url="auditor.aspx" title="Audit Page" />
        <siteMapNode url="admin.aspx" title="Admin Manager" />
    </siteMapNode>
 
</siteMap>

The first level SiteMapNode url and title is deduced for the current page url and description attribute of the page descriptors.

The second level SiteMapNode url and title is deduced from the path and description attribute of the navigation-path descriptor.

The SiteMap files enable the specification of site hierarchy and link structure. This could be data bound to Menus, TreeViews, etc.

We could add security to our specification, as shown below.

The corresponding SiteMap entries would be as shown below.

<?xml version="1.0" encoding="utf-8" ?>
 
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
 
    <siteMapNode url="default.aspx" title="Home">
        <siteMapNode url="approver.aspx" title="Approver Expenses" roles="approvers"/>
        <siteMapNode url="auditor.aspx" title="Audit Page" roles="auditors"/>
        <siteMapNode url="admin.aspx" title="Admin Manager" roles="admins"/>
    </siteMapNode>
 
</siteMap>