Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] - نسخه متنی

Andy Wigley; Peter Roxburgh

نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
افزودن یادداشت
افزودن یادداشت جدید






Container Controls

Two container controls allow you to group other controls. The Form control, which is the outermost container control, enables you to group controls into programmatic units. This grouping doesn't necessarily determine the final rendering of the controls, as you'll learn when we examine the Form control in this section. The Panel control is a convenient way of grouping controls within a form. Controls placed within a form or panel inherit style properties from their container, unless specifically overridden by the controls. The Panel control is a convenient way of applying common style properties to the group of controls contained within it. Figure 4-2 shows the class hierarchy of the Form and Panel container controls.


Figure 4-2: Class hierarchy of container controls


Containment Rules


Container controls provide a powerful means of structuring your Web application. However, you must understand the containment rules to which they adhere. As you've learned, all mobile Web Forms pages derive from the MobilePage class, which itself derives from the ASP.NET Page class. Therefore, every mobile Web Forms page is a valid MobilePage object. Each MobilePage object must contain one or more Form controls, which, as we've mentioned, you use to group controls into programmatically accessible objects.

A mobile Web Forms page can contain more than one Form control; however, you can't nest (or overlap) these controls. Each Form control can contain one or more mobile controls. These mobile controls can be of any type except other Form controls or style sheets. You can include zero or more Panel controls within a Form control; you can place other mobile controls inside a Panel control, thus allowing you to group controls within the Form. Unlike Form controls, you can nest Panel controls. For example, Panel control A can contain Panel control B, and Panel control B can contain Panel control C.

Figure 4-3 shows the relationships of the container controls and demonstrates how they can be nested.


Figure 4-3: Nesting Panel and Form controls


Form Controls


A Form control is the outermost container that resides within a MobilePage object. Each mobile Web Forms page must have one or more Form controls that in turn contain one or more mobile controls. Although you can't nest Form controls, you can use multiple forms within a single page, as Figure 4-4 shows.


Figure 4-4: Using the Form control

In addition to containing mobile controls, a Form control can contain literal text—that is, text outside the mobile controls. For example, in the Mobile Internet Designer, you can type literal text directly into the Form control. You can format the text by using formatting tags, which Table 4-3 describes.



























Table 4-3: Text Formatting Tags Used Within a Form Control


Tag


Description


<p> ...</p>


Places the enclosed text in a paragraph


<br> or <br/>


Inserts a line break


<b> ... </b>


Makes the enclosed text boldface


<i> ... </i>


Italicizes the enclosed text


<a href='url of resource'>Link -Text</a>


Inserts a hyperlink to another resource


When you use the tags in this table to display literal text, you can nest tags, but each set of tags must be enclosed completely by another. Server control syntax in a mobile Web Forms page adheres to XML structural rules. For example, the following code is valid:

<b><i>Hello World</i></b>

But the following code is invalid:

<b><i>Hello World</b></i>





Note

WML, HTML, and cHTML programmers will be familiar with these formatting tags. However, the tags don't specifically correlate to any of these markup languages. Rather, the formatting tags are abstractions of their counterparts in the three markup languages. For example, the runtime converts a break tag (<br/>) to the break tag that's appropriate for the target platform. A <br> tag will be delivered to HTML and cHTML browsers, while a <br/> tag will be delivered to a WML browser.






Warning

You can't use formatting tags within a mobile control element to format the text that it displays. Formatting tags can be used only where literal text is permitted. For example, the code

<mobile:Label runat="server"><b>Hello World</b></mobile:Label> isn't valid and therefore won't compile. To format the text contained within a mobile control element, you must use the control's properties.


Syntax


You code the Form control in server control syntax as shown in the following listing. (See Table 4-4 for more details on these properties.) Note that Action and Method affect the way in which data is transmitted from the client to the server. In most circumstances, you don't need to change these from the default values. Paginate is an important property that specifies whether the display of a form can be split across multiple display screens—if the requesting client is unable to handle the complete contents of the form in one go. The Child controls entry at the bottom of the listing identifies where you would place the server control syntax defining the controls within the Form.

<mobile:Form
runat="server"
id="id"
Font-Name="fontName"
Font-Size="{NotSet|Normal|Small|Large}"
Font-Bold="{NotSet|False|True}"
Font-Italic="{NotSet|False|True}"
ForeColor="foregroundColor"
BackColor="backgroundColor"
Alignment="{NotSet|Left|Center|Right}"
StyleReference="styleReference"
Visible="{True|False}"
Wrapping="{NotSet|Wrap|NoWrap}"
Action="url"
Method="{Post|Get}"
OnActivate="onActivateHandler"
OnDeactivate="onDeactivateHandler"
Paginate="{True|False}"
PagerStyle-NextPageText="text"
PagerStyle-PageLabel="text"
PagerStyle-StyleReference="styleReference"
Title="formTitle">
Child controls
</mobile:Form>




































Table 4-4: Significant Properties of the Form Control


Property


Type


Description


Action


String


The URL to which the form is submitted on a Post or a Get. The default is an empty string, which means the form does a postback to the same URL from which it was loaded. Has the same meaning as Action in HTML.


ControlToPaginate


Control


The ControlToPaginate property is used to allow a single control on a form to paginate, even when the form's Paginate property is set to false. This allows individual controls to be paginated instead of the entire form.


CurrentPage


Integer


Returns the index of the current page, once pagination occurs.


Method


System.Web.UI.MobileControls.FormMethod enumeration: Post|Get


The HTTP request method for a postback, which is either Post or Get. The default value is FormMethod.Post.


PageCount


Integer


Returns the number of pages a form is broken into when pagination occurs.


PagerStyle


System.Web.UI.Mobile-Controls.PagerStyle object


Sets or returns a PagerStyle object that specifies the text displayed and styles applied to the navigation prompts. The system automatically generates Next/Previous navigation as a result of pagination. Refer to Chapter 8 for details about usage.


Paginate


True|False


Boolean value of True or False that specifies whether pagination is permissible.


Title


String


The title of the form. Depending on the browser, this title can appear in a title bar, as a page heading, or not at all.


Properties


Table 4-4 lists the most important properties of the Form control. You set these properties either in server control syntax as described above or in code. The Type column describes the type of the property when setting or getting the property in code. Refer to the Syntax section above for valid values when setting the property in server control syntax. CurrentPage and PageCount are read-only properties that are set at run time as a result of pagination. You can't set them in server control syntax.

The controls contained within a Form control represent a single, addressable unit. However, this doesn't mean that the Form control will be displayed within a single unit on the client's browser. This is because the runtime adapts the output display to suit the target device by using pagination—meaning that the runtime breaks the output into smaller chunks. For example, a form collecting a user's personal details might split into a number of parts on a mobile phone to accommodate the phone's limited display capabilities. In contrast, the same form might appear as a single page on a device with a larger screen, such as a Pocket PC.

By default, the Form control doesn't paginate content. If you're testing an application on a small device and the device reports an error when attempting to load your Web page, the rendered size of the form might have exceeded the device's capacity. If this happens, enabling pagination might cure the problem. To disable pagination and thus ensure that the form's contents render as a single unit, you must set the Paginate property to False. Even if you disable pagination for the form, you can specifically enable it for one of the form's individual controls by setting the form's ControlToPaginate property to the ID of the control that you do want to paginate. This strategy might be appropriate for controls capable of displaying large quantities of output, such as any of the list controls or TextView.

The Form control has a number of events, including Activate, Deactivate, and Paginated. The Activate event occurs when a form becomes active, which can happen in the following instances:



A form is first requested.



A form is activated programmatically.



A user follows a link to a form.



The Deactivate event occurs when the current form becomes inactive, as in the following instances:



The user follows a link to a form, the current form is deactivated, and the new form is activated.



A new form is activated programmatically, and the current form is deactivated.



The Paginated event occurs when form pagination completes, which happens prior to rendering each request. After this event occurs, the CurrentPage property of the form contains the actual number of display pages for the form.

The Form control supports HeaderTemplate, FooterTemplate, and ScriptTemplate, templates that can be used to provide device-specific markup in the rendered form. Chapter 9 describes the usage of these templates.

Using the Form Control


Listing 4-1 displays a label and a link in a Form control. A second Form control displays a message. When the user clicks the link, the first form deactivates and the second form activates. The second form, which has a label, demonstrates how to use literal text in the Form control context.

Listing 4-1: Source code for FormExample.aspx






<%@ Register TagPrefix="mobile"
Namespace="System.Web.UI.MobileControls"
Assembly="System.Web.Mobile" %>
<%@ Page language="c#"
Inherits="System.Web.UI.MobileControls.MobilePage" %>
<mobile:Form id="Form1" runat="server">
<mobile:Label id="Label1" runat="server">
Form 1
</mobile:Label>
<mobile:Link id="Link1" runat="server" NavigateUrl="#Form2">
Link
</mobile:Link>
</mobile:Form>
<mobile:Form id="Form2" runat="server">
<b>
<i>Phew, you made it!</i>
</b>
<br>
<mobile:Label id="Label2" runat="server">
Form 2
</mobile:Label>
</mobile:Form>











Figure 4-5 shows the output of both forms on the Nokia simulator.


Figure 4-5: Output of the Form control example


Panel Controls


Panel controls don't have any visual appearance, but are used to logically group mobile controls. A Form control can contain zero or more Panel controls, and a Panel control can contain any mixture of controls, including other Panel controls but excluding Form controls. Unlike the grouping constructs you might have used before, Panel controls don't dictate the layout of the controls; the target platform always determines the control layout.

Syntax


You code the Panel control in server control syntax, as shown in the following listing. This control has no visual representation or events, but it possesses a number of properties that apply to the contained child controls through style inheritance. Apart from the common properties, Paginate is the only noteworthy property.

<mobile:Panel
runat="server"
id="id"
BreakAfter=="{True|False}"
Font-Name="fontName"
Font-Size="{NotSet|Normal|Small|Large}"
Font-Bold="{NotSet|False|True}"
Font-Italic="{NotSet|False|True}"
ForeColor="foregroundColor"
BackColor="backgroundColor"
Alignment="{NotSet|Left|Center|Right}"
StyleReference="styleReference"
Visible="{True|False}"
Wrapping="{NotSet|Wrap|NoWrap}"
Paginate="{True|False}" >
Child controls
</mobile:Panel>

Properties


Refer to Table 4-1 for details about how the common properties shown in the server control syntax work. These properties dictate the appearance of any text between the <mobile:Panel></mobile:Panel> tags and any child controls (controls contained within the panel). For example, if you set the value of Font-Bold to True, the panel's child controls will inherit this property and thus render the text in boldface. Not surprisingly, this behavior is device specific. For example, setting the ForeColor property to Red won't yield red text on a WML 1.1 browser because these browsers don't support color.

If you want to set style properties differently on specific devices, you can use a DeviceSpecific/Choice construct. The Panel control also supports the ContentTemplate template, which allows you to send arbitrary device-specific markup to a particular type of client. You'll learn more about the use of DeviceSpecific/Choice constructs and templates in Chapter 9.

The Paginate property is a hint to the runtime that it should try to keep the contained controls together when paginating. By default, this property is True. But if you set the Paginate property of the enclosing Form control to False, the Paginate property of the Panel control is ignored. When you enable pagination for the Form control and request pagination for an enclosed Panel control, the runtime attempts to keep the enclosed controls together on a "best-effort" basis.

Using the Panel Control


Listing 4-2 displays four Label controls. The first two labels appear within a Panel control. This panel also contains a panel, which contains two additional labels. The code sets font attributes for the panels but not the labels. When the code runs, the labels inherit the display characteristics of the panels. Therefore, all four labels are displayed in boldface and the last two labels are displayed in italics.

Listing 4-2: Source for PanelExample.aspx






<%@ Register TagPrefix="mobile"
Namespace="System.Web.UI.MobileControls"
Assembly="System.Web.Mobile" %>
<%@ Page language="c#"
Inherits="System.Web.UI.MobileControls.MobilePage" %>
<mobile:Form id="Form1" runat="server">
<mobile:Panel id="Panel1"
runat="server"
Font-Bold="True">
<mobile:Label id="Label1" runat="server">
Label 1 Panel 1
</mobile:Label>
<mobile:Label id="Label2" runat="server">
Label 2 Panel 1
</mobile:Label>
<mobile:Panel id="Panel2"
runat="server"
Font-Italic="True">
<mobile:Label id="Label3" runat="server">
Label 1 Panel 2
</mobile:Label>
<mobile:Label id="Label4" runat="server">
Label 2 Panel 2
</mobile:Label>
</mobile:Panel>
</mobile:Panel>
</mobile:Form>











Figure 4-6 shows how these four labels will appear in the Nokia simulator.


Figure 4-6: Output of the Panel control example

/ 145