Professional ASP.NET 1.0 Special Edition- P41 potx

<filter with="${versionString}" match="(?'browserMajorVersion'\w*)(?'browserMinorVersion'\.\w*).*"> majorVersion = ${browserMajorVersion} minorVersion = ${browserMinorVersion} </filter> mobileDeviceModel = "7110" optimumPageWeight = "800" screenCharactersWidth="22" screenCharactersHeight="4" screenPixelsWidth="96" screenPixelsHeight="44" </case> Here the match attributes are compared with the HTTP_USER_AGENT header to identify the device, and set the capabilities accordingly. The important thing to realize here, is that this is an extensible system. There are plenty of devices already in this file, but we can add our own, perhaps including the capabilities of the browser built into your fridge or whatever. We could even add devices that support some odd proprietary format should we wish to. Once these device capabilities have been set we have access to them from our code in two ways. The simplest is through the System.Mobile.MobileCapabilities class. This class has a number of properties that relate to device characteristics, such as the number of characters that can fit in a screen row, whether color is supported, and what markup language is preferred. <Choice> elements can access these properties via their capability attribute, which is how we chose the preferred markup type earlier. We were actually testing for the value of the preferredRenderingType property of the MobileCapabilities object containing information about the current browser. We can also access these capabilities programmatically. The following code outputs the value of preferredRenderingType to the screen: <mobile:Form runat="server" id="first" OnActivate="first_activate"> <mobile:Label runat="server" id="devCaps"/> </mobile:Form> <script runat="server"> Public Sub first_activate(o As Object, e As EventArgs) devCaps.Text = "preferredRenderingType = " & _ Device.PreferredRenderingType End Sub </script> resulting in: and: Using this method we can make dynamic choices in our code based on device capabilities. The other method is the one we briefly saw earlier, involving setting up filters and using them declaratively in our code. Setting filters involves adding <filter> elements to the <deviceFilters> section, of the <system.web> section, of the web.config file for your application. The format of these <filter> elements is simple: <filter name="filterName" compare="devCap" argument="compareString" /> We specify a name for the filter with filterName, a device capability (as specified in machine.config) with devCap, and a string to compare with the string content of the capability. The filters we set up earlier are now pretty self-explanatory: <deviceFilters> <filter name="isHTML32" compare="preferredRenderingType" argument="html32" /> <filter name="isWML11" compare="preferredRenderingType" argument="wml11" /> </deviceFilters> Once we have configured our filters we can use them in any mobile control with <DeviceSpecific> and <Choice> elements. The simplest use of these is to override or provide extra attributes, as with the earlier example: <mobile:Image runat="server" AlternateText="Cat" ImageURL="cat.bmp"> <DeviceSpecific> <Choice ImageURL="cat.wbmp" Filter="isWML11"/> </DeviceSpecific> </mobile:Image> Here, the only attribute of <Choice> that is specific to the <Choice> element is Filter, all others are applied to the parent control. This means that the ImageUrl attribute is overridden here. <Choice> elements can also be used to contain templates, which is the subject of the next section. Templates Much like the standard ASP.NET controls, it is possible to extend the way mobile controls are displayed using templates. Unlike ASP.NET controls we can do this on a device-by-device basis using the <DeviceSpecific> and <Choice> elements discussed in the last section. A given template will specify markup to use for display purposes, which, for example, might be as simple as specifying a section of HTML that is always output prior to the standard HTML output of a mobile control in a web browser, or might be more complex. There are five mobile controls that allow templating: <mobile:Form>, <mobile:Panel>, <mobile:Image>, <mobile:List>, and <mobile:ObjectList>. There are eight available templates:  ContentTemplate- markup for replacing entire control output  HeaderTemplate- markup to place before the control  FooterTemplate- markup to place after the control  LabelTemplate-markup to use for rendering the label of an item in an ObjectList  ItemTemplate- markup to use for each item contained in the control  AlternatingItemTemplate- markup to use for every other item contained in the control  ItemDetailsTemplate- markup to use for rendering the details for an item in an ObjectList  SeparatorTemplate- markup to place between each item contained in the control These apply to the templatable controls as shown in the table below. Control / Template Content Template Header Template Footer Template Label Template Item Template Alternating Item Template Item Details Template Separator Template <mobile:Form> Yes Yes Yes No No No No No <mobile:Panel> Yes No No No No No No No <mobile:Image> Yes No No No No No No No <mobile:List> No Yes Yes No Yes Yes No Yes <mobile:ObjectList> No Yes Yes Yes Yes Yes Yes Yes Templates are specified within elements having the same name as the template in question, and contain markup to use. The clever part here is that these elements are contained within <Choice> elements, allowing us to provide different templates for different devices (in much the same way as we saw different images being used in the <mobile:Image> control), for example: <mobile:Form runat="server" id="first" title="Back to Front"> <DeviceSpecific> <Choice Filter="isHTML32"> <HeaderTemplate> <table width="100%" cellpadding="4" cellspacing="2" bgcolor="black"> <tr> <td align="center" colspan="2" bgcolor="blanchedalmond"> Back to Front </td> <tr> <td width="25%" bgcolor="Gold" valign="top"> <a href="/index.aspx">Home</a> <a href="/links.aspx">Links</a> <a href="/about.aspx">About</a> <a href="/discuss.aspx">Discuss</a> <a href="/contact.aspx">Contact</a> </td> <td bgcolor="coral" valign="top"> </HeaderTemplate> <FooterTemplate> </td> <tr> </table> </FooterTemplate> </Choice> <Choice Filter="isUP4x"> <HeaderTemplate> Back to Front </HeaderTemplate> </Choice> </DeviceSpecific> The site that talks about what you don't want to hear about in a way that makes it too confusing to follow anyway! </mobile:Form> This code uses the header and footer templates to customize form layout. It requires the following filters in web.config: <filter name="isHTML32" compare="preferredRenderingType" argument="html32" /> <filter name="isUP4x" compare="type" argument="Phone.com 4.x Browser" /> On a WML browser the HTML template is ignored, and an additional plain text title is added to the display on an Openwave browser: On the Nokia 7110 this extra title isn't necessary, as the Title attribute of <mobile:Form>; works: However, on an HTML browser such as the Pocket PC we make much more use of the available capabilities: The other templates, when used with lists, can also be used to create excellent results, but I won't give an example of this here as their use is identical to formatting lists using the standard ASP.NET controls (although using a structure like the previous example's). Templates can also be placed in stylesheets such that they can be reused in multiple forms. The template used in the last example is a good candidate for this, as it provides a structure for containing body text that might apply well to several forms. Pagination Pagination is specified and controlled from <mobile:Form> controls. In most cases the pagination functionality supplied by default is enough for us, so Paginate is set to 'off'. It can be turned on as follows: <mobile:Form runat="server" id="first" Paginate="True"> </mobile:Form> Any text we specify in the form will then be split across screens where appropriate. For example: <mobile:Form runat="server" id="first" Paginate="true"> Tyger! Tyger! burning bright In the forest of the night What immortal hand or eye Could frame thy fearful symmetry? In what distant deeps or skies Burnt the fire of thine eyes? On what wings dare he aspire? What the hand dare seize the fire? And what shoulder, and what art, Could twist the sinews of thy heart? And when thy heart began to beat, What dread hand? and what dread feet? What the hammer? what the chain? In what furnace was thy brain? What the anvil? what dread grasp Dare its deadly terrors clasp? When the stars threw down their spears, And watered heaven with their tears, Did he smile his work to see? Did he who made the lamb make thee? Tyger! Tyger! burning bright [...]... really be an installation task Once the log is created, then you don't need any special permissions to write to the log If you do need to create a new log from within ASP.NET then you have two options, both of which involve the account under which ASP.NET runs This first option is to modify the configuration file so that ASP.NET runs under a different account - perhaps the system account This account... require special permissions to create new logs In Chapter 14, we discussed the ASPNET account that, by default, all ASP.NET pages run under, and this account doesn't have permissions to create new event logs This is because creation of new logs requires write permission in the registry, and by default, the ASPNET account doesn't require this By and large you shouldn't need to create new logs within your ASP.NET. .. for ASP.NET says, 'Errors happen Deal with it', and one developer I know says, 'Errors suck.' Both are true - however bad errors are, they do happen, and we have to find ways to track them down and prevent further errors In this chapter we are going to look at the features ASP.NET provides as help during the development cycle In particular we will look at: Tracing, and how to track progress through ASP.NET. .. page Viewing Trace Information To view the trace information, you navigate to trace.axd held in the root directory of the application This file doesn't actually exist, but is instead a special URL that is intercepted by ASP.NET It will give you a list of requests: Clicking on the View Details link for a request will then show the same trace details that would normally be shown at the end of each page... IErrorInfo will have these details mapped to the properties of the exception This topic is covered in more detail in Chapter 23 where we look at migration and interoperability ASP.NET Error Handling In addition to the CLR exception system, ASP.NET also provides ways of handling errors There are three ways in which this can be done: At the page-level error event for errors on an individual page At the application-level... your users being aware of the information Writing output to a text file or database would probably be the best solution here You can actually create some quite elegant solutions for tracing, but with ASP.NET, we have everything neatly encapsulated for us What's particularly cool is that you can decide if you want tracing managed on a page-by-page basis, or for the entire application Page-Level Tracing... you can see there are just a couple of lines of text To enable tracing for this page, you set the Trace attribute of the Page directive to True Adding this to the top of your ASP.NET page will give you the following output: Apart from that one line of code, nothing has changed in the page, and yet, we have got a whole heap of information This is all automatically generated... all other unhandled errors will go to DefaultErrorPage.aspx You can have multiple error elements to cater for multiple HTTP errors Notifying Administrators of Errors The rich set of error handling that ASP.NET provides is a great way to trap errors, but the users aren't the only people who need to know that something has gone wrong A user will see the error page, but administrators and developers also... Exception Trace.Warn("Error", "Message here", E) End Try Turning Off Tracing One of the problems with the old ASP method of tracing was that we had to remove the trace statements when we were done With ASP.NET, all you do is turn off tracing either by setting the page directive or using the IsEnabled property You don't have to remove the Trace statements themselves, or comment them out, because if tracing... using the registry or a configuration file to identify whether tracing is enabled or not, are also possible Tracing from Components The same method of tracing is available to components called from an ASP.NET page, allowing them to integrate seamlessly with your pages To access the Trace functionality, you have to import the System.Web namespace, reference the current HttpContext object and get its . ${browserMinorVersion} </filter> mobileDeviceModel = " 711 0& quot; optimumPageWeight = " 800 " screenCharactersWidth="22" screenCharactersHeight="4". argument="html32" /> <filter name="isWML 11& quot; compare="preferredRenderingType" argument="wml 11& quot; /> </deviceFilters> Once we have configured. section. Templates Much like the standard ASP. NET controls, it is possible to extend the way mobile controls are displayed using templates. Unlike ASP. NET controls we can do this on a device-by-device