This captures all events that could originate from the page, including information on the handler objects that process these events on the server side.

It should first be noted that events involving client scripting like mouse over effects, are not captured by the event descriptors. These specifications are strictly in regard to page interactions with the server.

In short, the event descriptors capture specification on 1) all event triggers on the page, and 2) provide associations between them and their handlers on the server side.

One method of providing handlers to page events is through backing beans or code behind. In these cases, backing beans or code behind that contain these handlers, would be declared in the behavior-define descriptors, along with other objects exposed to the page. It is based one these defined objects that the method bindings used for event handling are specified in the event descriptor.

Another way to expose handler object for use on the page is by associating a URL path to the event handler. This URL path, with optional method designation, would then be specified as the handler for the event. These are rarely involving page event, but more related to action events. As such, they are referred to as action paths, and action handlers.

dWebSpec provides for both means of exposing handlers to the page.

The subject of event could be divided into those pertaining to the page, and those involving elements within the page. Our discussions shall be along these separate lines.

Page Event

The primary page event involves activities that are precursor to or those that occur on page load. Such specification is as shown below.

NOTE: For most other platforms the handler and handler methods could vary, and could be multiple. For ASP.NET, it must be the code behind (bb) and PageLoad() method.

Example of this handler method within the code behind is shown below.

protected void Page_Load(object sender, EventArgs e)
{
     Label1.Text = DateTime.Now.ToString();
}
 

NOTE: A true page load routine should not be invoked on post back. As mentioned about, page action precedes the presentation of the page for the interaction. Interaction with the page and send back to server is characterized as post back. To avoid the action serving both initial and post back actions, an if clause should be added as shown below.

protected void Page_Load(object sender, EventArgs e)
{
     if (!isPostBack) {
         Label1.Text = DateTime.Now.ToString();
     }
}

The specification captured would lead to the implementation of an empty method. As we shall see, other associated entries like the parameters and security related ones could influence the method implementation.

Page Parameters

dWebSpec allows the capture of page event as well as the parameters passed to the page, providing a snapshot of parameters used on the page. These specified parameters are passed to the page on initial load in form of query string or standard HTML form attributes.

An example specification is shown below.

The parameters referenced are stored in the parameters descriptor as shown below.

The implementation could simply be is shown below:

String type = Request.QueryString["type"];   

Example of the usage of such parameters could be found in the behavior-define section.

Component Tree as Parameter

In accordance with MVC layering, this is not a good practice. However, the parameters passed to a page, could be the component tree and data therein (view state) of another page. It is not good to couple two pages together; it would make adding an intermediate page a chore. The term used for this, on the .NET platform, is Cross-Page posting. The specification for such parameters is shown below.

There is programmatic access to the object tree through PreviousPage object, as shown below.

protected void Page_Load(object sender, EventArgs e)
{
  if (PreviousPage != null) {
    Label1.Text = "You came from a page titled " +
      PreviousPage.Header.Title
  }
}

Page Security

Page security could be specified as shown below.

The security specification in this descriptor entails a comma delimited list of roles. For ASP.NET there is no declarative way to implement this specification. What could be handled declaratively is path security.

The distinguishing factor is that the event security is through handlers in the controller, whereas navigation path security falls under the general navigation scheme. The latter might not involve handlers, like path to static pages, or path to associated sites.

It is the latter, as we shall see in the navigation-path descriptor section that has declarative security implementation.

However, through custom coding, one could include authorization and authentication check in the Page_Load event handler. The sample specification above could be implemented as shown below.

protected void Page_Load(object sender, EventArgs e)
{
  if (HttpContext.Current.User.IsInRole("admin") ||
         HttpContext.Current.User.IsInRole("sale")) {
    // do something
  }
}
 

Although example above features roles, the specification could involve user principals alone or in combination with roles.

The full repertoire of possible specifications is discussed under navigational security; the same options are applicable here. The difference being custom implementation is the only option for page security, whereas navigational security could be handled declaratively.

We will explore two other specification options. Whenever an asterisk is specified for the security, it would imply any role, which again implies any authenticated user. This is specified as shown below.

The implementation would be as shown below.

protected void Page_Load(object sender, EventArgs e)
{
  if (Request.IsAuthenticated()) {
    // do something
  }
}

Although not usually advisable, since personnel could change, there is provision for specifying user names in security specifications. This could be specified as shown below.

The format is group:name, however the group could be blank. The implementation would be as shown below.

protected void Page_Load(object sender, EventArgs e)
{
  if (Request.IsAuthenticated() &&
		HttpContext.Current.User.Identity.Name == "ajohnson") {
    // do something
  }
}

Element Event

The discussion above covers the page event; the coverage here is on events that are triggered by elements (controls) on the page. A typical specification along this line is shown below.

Handler is an instance of the backing bean, this is called code behind; the specification of the bb (backing bean) object could be implicit or represented in the behavior-define descriptor. We are focusing on the event descriptor; as such the element is shown as the source only. Other specification for the element would be in the element descriptor. The other implementation details would be derived from the element descriptor and the content source.

The implementation of the element would be as shown below.

<asp:button id="EnterBtn" text="Enter" Onclick="EnterBtn_Click" runat=server/> 

There are some points to note here. The development on the .NET platform is usually facilitated by the use of interactive IDE. This is because, on this platform, the IDE does a lot for a programmer. For instance, by clicking on the button component in the graphical editor, the shell of the event handler could be created or selected from a drop down menu.

These points should also be noted.

1. There is a naming convention for the handler {control-id_event}.
2. The Onclick handler is for the server side event; the client side event is handled by OnClientClick.
3. The method binding (as illustrated with the Onclick attribute) is without the object prefix, since the code behind is the handler for any event invoked from the page. The page (web form) and the code behind are actually a single object, declared separately as “partial” classes.

The implementation code for the event handler could appear as below.

        void EnterBtn_Click(Object Src, EventArgs E) {
            Message.Text = "Hi " + Name.Text + ", welcome to ASP.NET!";
        }
  

It is noteworthy that ASP provides an option “auto-wire” that allows implicit invocation of handler based on the event, without having to specify the handler in the element implementation. The system knows which handler to call based on a naming convention that includes the source element id and the event. To put this scheme onto effect the auto wire attribute must be set to true, as shown below.

 <%@ page language="C#" CodeFile="CodeBehind_cs_aspx.cs" 
			Inherits="_Default" AutoEventWireUp="true"%>

Irrespective of whether auto wire is in use or not, it adds a lot of clarity to the specification, if the handler is shown explicitly in the specification. It would show which ones of the possible handlers are actually in use.

Element Event Parameter

Event parameters for elements capture the data passed to the server as part of the event invocation. For a typical form submission, the parameters passed are the bound fields within the form.

For ASP.NET, as a component based platform, the parameters passed is implicit. All elements on the page are represented as part of the component tree, which the platform keeps track of. The information kept, goes beyond bound values and could include the presentation state. In essence, the view state is the parameter passed to the server whenever submit, or post, or post back type events are invoked.

For other events, like the change event, their signature and parameters are also fixed by the platform.

In short, the parameter entry does not play a part in most of the event entries for elements.

One area in which the capture could be necessary is an event involving elements of type link, with call type GET, which is the default. Those could involve series of key and value pairs.

First the representation in the descriptor is explained here. The link element would show up in the element descriptor.

Its event would show up in the event descriptor, associated with event-source attribute.

The parameters "identity" would be derived from the parameters descriptor.

The resulting path would show in the navigation-path descriptor. The link between the navigation path descriptors and the event is the handler, if there is any, or the id of the event. In this case there is no handler; the example is shown below.

The implementation code would be as shown below.

 <asp:hyperlink id="ShowCust" runat="server"
    navigateurl='<%# String.Format("http://yoursite.com/showcustomer.aspx?id={0}&city={1}",
    Eval("ID"), Eval("City")) %>' text='<%# Eval("CustomerName") %>' /> 

The data source for the bindings would be the customer in the {customer.ID}, {customer.City} value binding. This would be derived from the parent container like the FormView Control.

When the link resides within the gridView, the implementation would be slightly different.

<asp:HyperLinkField runat="server"
         DataTextField="CustomerName"
         DataNavigateUrlFields="ID,City"
         DataNavigateUrlFormatString=
         "http://yoursite.com/showcustomer.aspx?id={0}&city={1}" />

Event to Control Mapping

The correspondence between dWebSpec event descriptor attributes and the ASP.NET component attributes is shown in the table below. For more details, follow the link for the attributes.

Event Types

Listed below are the event handlers (using auto wire conversion) applicable to the different element types.

AJAX

Whenever a call-type of ajax is prescribed, as shown in the descriptor below, there are two potential implication. First, an AJAX aware component should be prescribed, or AJAX extender must be in use.

ASP.NET provided a wealth of AJAX aware components; these are discussed further in the section describing the AJAX call type. Apart from these components, there are the AJAX extenders that could be used to provide specific AJAX or scripting functionalities to specific type of controls. These are also discussed in the afore-mentioned section.

Whenever an event with a call-type ajax is associated with a segment, it would imply that for the segment partial refresh is in use. This association is established with the event-id attribute of the segment descriptor. This is discussed in under the subject of segment descriptor, attribute event-id.