Despite all the nice UI and usability offerings of AJAX nothing beats a real windows control. These days you can do terrific things on a web form but when it comes to things like drag and drop between the nodes of different treeviews a real windows control is the way the go. In an old post I already demonstrated how to include something like tablet pc functionality in a web page. Since then I’ve been building another web-hosted user control, let me share some of the new things I learned.
There is a good tutorial on the basics of building a control over here on MSDN. For my example I have built myUserControl which is in the assembly myLibrary. Including the user control on the client is a matter of client side html. Displaying the control in the page is done in an html object.
When rendering the page IE expects the assembly MyLibrary.dll alongside the aspx on the server. It will download the assembly and extracts the class MyNameSpace.MyUserControl. From this class it creates the user control which is displayed in the space reserved for the object.
For this to work well the following requirements are put on the client
- Use Internet Explorer. This does not work in any of the other browsers.
- Have the .NET framework installed on the client machine.
- The site should be included in the trusted sites list of the browser.
- The browser should be allowed to download files from the (trusted) site.
Note that when your user control uses other custom assemblies, not part of the installed framework, the control will not display. The assembly itself is downloaded, the dependencies are not. Also note the security settings. It is easy to drown in the IE 7 security settings. Allowing a file download is something which you explicitly have to do by hand. When all these requirements are not met the object will be an empty space on the page, filled with the default “image missing” icon.
The location of the assembly is read by the browser as an http address. Just the filename assumes the assembly alongside the aspx on the server. Setting a different location is a matter of setting an URL
To make this configuration configurable requires a little twist, as this markup is static html. The way to manipulate static html server-side is using an asp.net literal control.
<asp:Literal ID=”Literal1″ runat=”server”></asp:Literal>
The contents of the literal is manipulated from serverside code behind.
This will result in exactly the same html and, provided the assembly is found at the url (and all other (security) settings are in place), the control will display in the browser.
The usercontrol can interact with the other parts of the page. All its public members are accessible from script. All events as well, the MSDN article dives deeper into that. Beside manipulating the control from script it’s public properties can also be set on initialization.
This way public properties are initialized. It works well over different types, you can even pass enumeration members. The nice thing about this construction is that it also can be done from the server side code behind while constructing the html for the literal control.
Literal1.Text = string.Format(objectTemplate, objectUrl, sb.ToString());
Note the enumeration member being passed.
It is possible to invoke public methods from script. But here we invoke the initialization method by setting a property.
Having set all properties a configurable method is fired. There is no need for any script yet. But there is one thing where ajax can play a very important and handy role. On every roundtrip the usercontrol is reinitialized and any changes in its state are gone. Putting all other controls which cause a roundtrip on an ajax updatepanel are the way to keep this under control. The partial updates will now preserve the state of your user control.
That’s all there is to it. First build you user control, of course best in a TDD style, and then check what it looks like in IE. It will look good but be prepared for a slightly different appearance. Have fun !