Hello, World Web Form Style
"Hello, World" Web Form Style
Far be it from me to break the tradition established in this book, so let's create the first Web application as a "Hello, World" application. Actually, it is a "Hello <name>" application, but let's not be picky.
Managed C++ ASP.NET Web pages will always be made up of at least two files: the HTML/XML .aspx file and the Managed C++ codebehind file. In general, the .aspx file's purpose is to provide a definition of the Web interface of the application, and the codebehind provides code logic to support that interface.
In the case of HelloWorld, the .aspx file (see Listing 14-4) contains a simple interface that allows a user to enter his or her name and then, after clicking a button, have the name regurgitated back to him or her prefixed with "Hello". You should put HelloWorld.aspx in the Web Forms folder.
Listing 14-4: HelloWorld ASP.NET Style
 |
<%@ Assembly Name="HelloWorld" %> <%@ Page Inherits="HelloWorld.HelloForm" %> <html> <head> <title>Hello World!</title> </head> <body> <form method="post" runat="server"> <P> <asp:Label runat="server">Enter Your Name:</asp:Label> <asp:TextBox runat="server"/> </P> <P> <asp:Button runat="server" Text="Click Me!"/> </P> <P> <asp:Label runat="server"/> </P> </form> </body> </html>
|
| Note | For those of you who aren't familiar with the server controls (i.e., the tags starting with <asp: xxx>), you might want to consider reading up on ASP.NET before continuing with this chapter. I'm not including an explanation here simply because the size of the topic is just too big for (and really not relevant to) this book. |
| Tip | It's possible to drag and drop the controls to the Web Form and update the controls' properties in the Properties view. Just make sure that you manually place all the code outside of the <form></form> tags in your .aspx file before you drag and drop controls into it. |
The code is pretty standard ASP.NET code. The only things of note are the @ Assembly and @ Page directives:
<%@ Assembly Name="HelloWorld" % <%@ Page Inherits="HelloWorld.HelloForm" %>
The @ Assembly directive Name attribute associates a precompiled assembly with this page. IIS will expect to find this assembly in the bin directory off of the Web application's root virtual directory. Note that even though the assembly ends in .dll, you can't include it in the Name attribute, as it will cause an exception to be thrown when the Web page is accessed.
The @ Page directive has many attributes. Normally, it is here that you would find the attribute for the default language to be used. Because Managed C++ is not one of the supported embedded languages, you do not include the default language attribute. The minimal @ Page directive includes only the Inherits attribute, which associates a specific class out of the assembly with this page. Notice that if you use namespaces within the assembly, you also need to add them to the Inherits attribute.
The basic operation of the Web Form when requested by the user browser is that the ASP.NET runtime creates a Page class inherited from the precompiled assembly/class specified by the @ Assembly and @ Page directives. This Page class, along with the visual elements of the .aspx file, is compiled and executed. Upon executing, HTML is generated and sent back to the requesting user's browser.
The key to the capability for ASP.NET to work with Managed C++ is that the Page class generated by the ASENET runtime inherits from standard .NET assemblies, which Managed C++ creates.
Let's continue the example (see Listing 14-5) by examining the Managed C++ codebehind. By convention, it's named the same as the .aspx file suffixed by .h. But in reality, you can name it just about anything you want, as long as it's included in the linker (.cpp) file (which you'll cover later), so that it can be compiled into a library assembly. You should put HelloWorld.aspx.h in Class Files folder.
Listing 14-5: The HelloWorld Managed C++ Codebehind
|
using namespace System; using namespace System::Web::UI; using namespace System::Web::UI::WebControls; namespace HelloWorld { public __gc class HelloForm : public Page { protected: TextBox *Input; Button *ClickMe; Label *Output; void OnInit(EventArgs *e) { ClickMe->Click += new EventHandler(this, ClickMe_Click); Page::OnInit(e); } private: void ClickMe_Click(Object *sender, EventArgs *e) { Output->Text = String::Format(S"Hello {0}", Input->Text); } }; } |
Just like the preceding ASP.NET code, this is pretty standard Managed C++. For those of you who have coded ASP.NET in C#, this code will look quite familiar. Except for the asterisks and a few double colons, this code is, in fact, virtually the same as that of a C# codebehind.
The preceding code is about the minimum you can get away with when it comes to this Web page. To get the Web Form to compile, you need references to the following assemblies:
-
Mscorlib.dll
-
System.dll
-
System.Web.dll
Unexpectedly (at least to me), these references automatically get added when you add HelloWorld.aspx, along with a few others. Is ASP.NET going to support Managed C++ in a future release? Having these references automatically show up suggests that to me. Guess I'll just have to wait and see.
The only new reference is System.Web.dll, which is needed to provide browser-to-server communications. This assembly is needed for all Web applications.
Next, you import the namespaces used by the codebehind:
using namespace System; using namespace System::Web::UI; using namespace System::Web::UI::WebControls;
The namespace System::Web::UI contains classes and interfaces that allow the creation of ASP.NET server controls and pages. These server controls and pages will appear in your Web applications as user interface elements.
There are two types of controls available to you when you're developing ASP.NET pages: HTML server controls and ASP.NET Web Form controls. I personally use Web Form controls because I find them more consistent and easier to work with than HTML server controls. If you come from the HTML server control school, you'll need to change the preceding code to use your types of controls, but the basic logic will remain the same. Table 14-1 shows the ASP.NET Web Form control and its equivalent HTML server control.
| ASP.NET WEB FORM CONTROL | HTML SERVER CONTROL |
|---|---|
| <asp:Button> | <input type="button"> or <input type="submit"> |
| <asp:CheckBox> | <input type="checkbox"> |
| <asp:DropDownList> | <select><option selected> |
| <asp:Hyperlink> | <a> |
| <asp:Image> | <img> |
| <asp:ImageButton> | <input type="image"> |
| <asp:Label> | <span> |
| <asp:LinkButton> | <a><img/></a> |
| <asp:ListBox> | <select> |
| <asp:ListItem> | <option> |
| <asp:Panel> | <div> |
| <asp:RadioButton> | <input type="radio"> |
| <asp:Table> | <table> |
| <asp:TableCell> | <td> |
| <asp:TableRow> | <tr> |
| <asp:TextBox> | <input type="text"> or <input type="password"> or <textarea> |
Because the example uses ASP.NET Web Form controls, it imports the namespace System::Web::UI::WebControls. If it were to use HTML server controls, it would need to import the namespace System::Web::UI::HtmlControls. It is also possible to use both control types within the same Web page. I personally think that, in most cases, combining the two control types could make things a little more confusing than necessary.
Once you have all the references and namespaces straightened away, you finally create the Page-derived Managed (__gc) class, which the Web page will inherit from:
public __gc class HelloForm : public Page
To access the controls in the Web Form, you need to create definitions of the controls. Notice that the id attribute matches the name of the control definition. Each of these controls will have instances created for them by the Web page-created class. Once instantiated, you have complete access to these controls' properties and methods using these variables' definitions:
TextBox *Input; Button *ClickMe; Label *Output;
The processing of Web pages (see Table 14-2) and controls is by events. You get access to these events using event handler delegation. You can reference Chapter 4 for a refresher or Chapter 9, as Windows Forms use a very similar method.
| EVENT | DESCRIPTION |
|---|---|
| Error | Triggered when an unhandled exception is thrown |
| Init | Triggered when the controls are first initialized |
| Load | Triggered when the controls are loaded onto the page |
| Unload | Triggered when the controls are unloaded from the page |
The Page class provides a handy virtual member called OnInit(), which triggers the Init event. To enable the codebehind to delegate its own event handlers, you need to override this method:
void OnInit(EventArgs *e) { ClickMe->Click += new EventHandler(this, ClickMe_Click); Page::OnInit(e); } | Caution | Be very careful to remember to call the Page base class version of this method so that any functionality in the Page class's OnInit() method will also be executed. |
In this example, the codebehind delegates an event handler to the Button control's Click event.
The final method found in the HelloWorld class is the event handler for the clicking of the Click Me! button. The logic simply copies the Input text control's Text property, prefixed with "Hello," to the Text property of the Output Label control.
void ClickMe_Click(Object *sender, EventArgs *e) { Output->Text = String::Format(S"Hello {0}", Input->Text); } Anyone who has worked with Win Forms should see a strong similarity between the handling of events in Web Forms and in Win Forms. There are some major differences. The biggest is that not all controls immediately trigger an event that will be handled by the Web application. The round-trip from the client machine to the server can be expensive time-wise; thus some events are cached and then sent as a bundle to the server to be handled. For example, much of the default event handling of list box selection for the list box and the drop-down list box is done on the client machine. It should be noted, though, that it is possible to change this default behavior by setting the attribute AutoPostBack to true, which will then cause the item select events to be sent to the Web application.
Now that you have all the pieces needed to create a Web Form, you have to be able to precompile the codebehind so that it can be run by the Web server. You do this simply by adding the codebehind to the linker file HelloWorld.cpp (see Listing 14-6), which was autogenerated with the creation of the project.
Listing 14-6: The Linker File HelloWorld.cpp
|
#include "Global.asax.h" #include "HelloWorld.aspx.h"
|
Though it's not really needed because you aren't handling any application-level events, I have included a link to Global.asax.h as well as HelloWorld.aspx.h. Now all you need to do to precompile the assembly is to ... ah, precompile it.
Let's see if your handiwork was successful. Press Ctrl-F5, which compiles the HelloWorld assembly into the bin directory and then starts the Web page. In the dialog box that appears, enter http://localhost/HelloWorld/HelloWorld.aspx in the edit box "URL where the project can be accessed" (see Figure 14-6).
Figure 14-6: HelloWorld - Executable for Debugging Session dialog box
Now, if all went well, you should see something similar to Figure 14-7 in your browser. If you don't see this, try debugging the Web page.
Figure 14-7: The HelloWorld Web page
EAN: 2147483647
Pages: 169