binding XmlDataSource to GridView

Binding XmlDataSource to Menu or ViewTree control is pretty simple, but there is a little difference if binding XmlDataSource to a GridView control. There are two ways to bind the XmlDataSource to GridView: one is using XPath binding and the other is using XSLT.

Here is the data in the xml file “cities.xml” that will be used in all the cases here:

<?xml version=”1.0″ encoding=”utf-8″ ?>
<Countries>
   <continent name=”NorthAmerica”>
      <country name=”USA”>
         <language>English</language>
         <capital>Washington D.C</capital>
         <cities>Houston</cities>
      </country>
   </continent>
   <continent name=”Europe”>
      <country name=”France”>
         <language>Franch</language>
         <capital>Paris</capital>
         <cities>Lyon</cities>
      </country>
   </continent>
   <continent name=”Asia”>
      <country name=”China”>
         <language>Chinese</language>
         <capital>Beijing</capital>
         <cities>Shanghai</cities>
      </country>
   </continent>
</Countries>

First of all, let’s have a look at binding XmlDataSource to a TreeView control:

1. create a XmlDataSource object and config it as in the figure 1
2. create a TreeView object and set the dataSource to XmlDataSource1
3. click “Edit TreeNode Databindings…” to popup the “TreeView DataBindings Editor”, and set the TextField as “#InnerText” for each selected data bindigns. Otherwise, only the attribute values will show up.
4. run it, and will see:

If do this to a GridView, nothing would show up. It would not work. We have to do something different from this for GridView control. There are two ways.

Let’s see binding XmlDataSource to GridView by using XPath binding with itemtemplate:

1. create a GridView object
2. change the code as following:

         <asp:GridView ID=”GridView1″ runat=”server” AutoGenerateColumns=”False” DataSourceID=”XmlDataSource1″ style=”margin:20px;”>
           <Columns>
          <asp:TemplateField>
          <ItemTemplate>
          <%#XPath(“@name”) %>
          </ItemTemplate>
          </asp:TemplateField>
          <asp:TemplateField>
          <ItemTemplate>
          <%#XPath(“country/@name“) %>
          </ItemTemplate>
          </asp:TemplateField>
          <asp:TemplateField>
          <ItemTemplate>
          <%#XPath(“country/language”) %>
          </ItemTemplate>
          </asp:TemplateField>
           <asp:TemplateField>
          <ItemTemplate>
          <%#XPath(“country/capital”) %>
          </ItemTemplate>
          </asp:TemplateField>
          <asp:TemplateField>
          <ItemTemplate>
          <%#XPath(“country/cities”) %>
          </ItemTemplate>
          </asp:TemplateField>
         </Columns>
       </asp:GridView>

Here is the result:

The other way seems a little complicated because we need to create a XSLT file, but it might be more flexible and powerful.

1. create a XSLT file saved as “cities.xsl” for transforming to another xml having different structure, and the code is:
2. <?xml version=”1.0″ encoding=”utf-8″?>
   <xsl:stylesheet version=”1.0″
       xmlns:xsl=”http://www.w3.org/1999/XSL/Transform“>
      <xsl:output method=”xml” indent=”yes”/>
      <xsl:template match =”/”>
         <Countries>
            <xsl:for-each select=”Countries/continent”>
               <continent>
                  <xsl:attribute name=”continent”>
                     <xsl:value-of select=”@name”/>
                  </xsl:attribute>
                  <xsl:attribute name=”country”>
                     <xsl:value-of select=”country/@name”/>
                  </xsl:attribute>
                  <xsl:attribute name=”language”>
                     <xsl:value-of select=”country/language”/>
                  </xsl:attribute>
                  <xsl:attribute name=”capital”>
                     <xsl:value-of select=”country/capital”/>
                  </xsl:attribute>
                  <xsl:attribute name=”cities”>
                     <xsl:value-of select=”country/cities”/>
                  </xsl:attribute>
               </continent>
            </xsl:for-each>
         </Countries>
      </xsl:template>
   </xsl:stylesheet>
3. reconfig the XmlDataSource1 as:
4. 
5. run it, and will see the result:    

In fact, cities.xsl transforms the cities.xml to:

<?xml version=”1.0″ encoding=”utf-16″?>
<Countries>
  <continent continent=”NorthAmerica” country=”USA” language=”English” capital=”Washington D.C” cities=”Houston” />
  <continent continent=”Europe” country=”France” language=”Franch” capital=”Paris” cities=”Lyon” />
  <continent continent=”Asia” country=”China” language=”Chinese” capital=”Beijing” cities=”Shanghai” />
</Countries>

and GridView can show up the elements’ attribute values.

it is not easy to use the XmlDataSource to edit XML data

The XmlDataSource control is commonly used in read-only data scenarios where a data-bound control displays XML data. However, you can also use the XmlDataSource to edit XML data. Note that automatic update, insert, and delete operations that work with other data source controls will not work. You must write custom code to modify data using the XmlDataSource control.

store/access resource in assembly/xap/site

Now we are talking where to store the resources(files), like image, and how to access them.

We have  a silverlight project “TestAssembly”. Add an image into it. And then we need think about the image property.

If the Build Action of  its property is set to “Resource”, the image file will be included into the silverlight assembly (dll) when do compilation. It can be accessed from xaml like:

<Image Source=”myImage.jpg” />

If the Build Action of  its property is set to “Content”, the image file will be included into the silverlight XAP when do compilation. It can be accessed from xaml with a leading slash “/”:

<Image Source=”/myImage.jpg” />

If silverlight app could not find any image in its assembly or xap file, it would go bin (clientBin) folder of the web application to find it. So, it means the resources (image files) could be directly put in the bin/ClientBin folder.

Silverlight app can access resources in another assembly. Create a new silverlight project “ResourceAssembly” and add an image in it: “newImage.jpg” with Build Action property set by “Resource”. So the xaml of “TestAssembly” can access it by:

<Image Source=”/ResourceAssembly;Component/newImage.jpg” />

first look on silverlight

Spent several days (~20 hrs) on reading the book “silverlight 2 visual essentials”.

This 240-page book is easy to read and understand (mostly). It provides only the basic content about the silverlight. It doesn’t include many examples and its examples are really basic. I could not remember it has any example that explains several attributes/features/functions togather. But it is good enough for a book with only 240 pages.

There are 3 things that I need read or practice again, or maybe need to find something else to read:

• dependence property is not easy to understand. But it is a key point in silverlight.
• need to understand more about the chapter 5 “the application model” before start with any project.
• could not understand well about “geometry mini-language” without any practice.

This book only has 8 pages describing 2D drawing and 4 pages describing animation. So, definitely, will find other books to know them.

Rate on it is 4 of 5. The reasons for minus 1 are:

• could not understand well  about dependence property, even I read twice.
• That would be better if it could provide any interesting example.

This is an introduction book, so,  it’s ok it does not cover any advanced topic.

DOM Tree

XMLHttpRequest properties and methods

Create XMLHttpRequest object

var xmlHttp = false;
function getXmlHttpRequestObject() {
 // check for native XMLHttpRequest object
 if(window.XMLHttpRequest && !(window.ActiveXObject)) {  
  try {
   xmlHttp = new XMLHttpRequest(); 
  }
  catch(e) {
   xmlHttp = false;
  }
 }
 // check for IE/Windows ActiveX version
 else if(window.ActiveXObject) {
  try {
   xmlHttp = new ActiveXObject(“Msxml2.XMLHTTP”);
  }
  catch(e) {
   try {
    xmlHttp = new ActiveXObject(“Microsoft.XMLHTTP”);
   }
   catch(e) {
    xmlHttp = false;
   }
  }
 }
}

The XMLHttpRequest object can make requests only to the same domain as the currently loaded page. This security policy is also known as the “same origin” policy.

Page Life Cycle Events

1. Page_Init: initializing the controls.
2. LoadViewState: restores the View State.
3. LoadPostData: restores the View State.
4. Page_Load: populate and bind data to controls
5. RaisePostDataChangedEvent:
6. RaisePostBackEvent
7. Page_PreRender: make changes to the data contained in controls prior to their rendering.
8. SaveViewState
9. Page_Render: creates the Response object and uses a text writer to write the response stream to the Response.
10. Page_UnLoad: unloaded from the memory, and the Response object is sent to the browser.

Comparing Web Site Projects and Web Application Projects

The following table lists Web project options or tasks and indicates which project model best implements those options.

Option or Task	Web App Projects	Web Site Projects
Need to migrate large Visual Studio .NET 2003 applications	X
Prefer single-page code model to code-behind model		X
Prefer dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).		X
Need to control names of output assemblies	X
Need to generate one assembly for each page		X
Need stand-alone classes to reference page and user control classes	X
Need to build a Web application using multiple Web projects	X
Need to add pre-build and post-build steps during compilation	X
Want to open and edit any directory as a Web project without creating a project file		X

The following table helps you select a project type by describing some of the key differences between Web application projects and Web site projects.

Scenario	Web Application Project	Web Site Project
Project definition	Similar to Visual Studio .NET 2003. Only files that are referenced in the project file are part of the project, are displayed in Solution Explorer, and are compiled during a build. Because there is a project file, some scenarios are more easily enabled:You can subdivide one ASP.NET application into multiple Visual Studio projects.You can easily exclude files from the project and from source code-control.	Web site projects use the folder structure to define the contents of the project. There is no project file and all files in the folder are part of the project.This project type is desirable if you have an existing folder structure representing an ASP.NET application that you want to edit in Visual Studio without having to explicitly create a project file.
Compilation and build outputs	The compilation model for Web application projects is very similar to that in Visual Studio .NET 2003.All code-behind class files and stand-alone class files in the project are compiled into a single assembly, which is placed in the Bin folder. Because this is a single assembly, you can specify attributes such as assembly name and version, as well as the location of the output assembly.Certain other applications scenarios are better enabled, such as the Model-View-Controller (MVC) pattern, because they allow stand-alone classes in the project to reference page and user control classes.	The Build command compiles Web site projects only to test them. To run Web site projects, you deploy source files and rely on ASP.NET dynamic compilation to compile pages and classes in the application.Alternatively, you can precompile the site for performance, which uses the same compilation semantics as ASP.NET dynamic compilation. The ASP.NET dynamic compilation system has two modes—batch mode (the default) and fixed-names mode. In batch mode, many assemblies (typically one per folder) are produced when precompiling the site. In fixed mode, one assembly is produced for each page or user control in the Web site.
Iterative development	To run and debug pages, you must build the entire Web project. Building the entire Web application project is usually fast, because Visual Studio employs an incremental build model that builds only the files that have changed.	You can configure build options Visual Studio 2005 for when you run the site: build the site, an individual page, or nothing at all. In the last case, when you run a Web site, Visual Studio simply launches the browser and passes to it the current or start page. The request then invokes ASP.NET dynamic compilation.Because pages are compiled dynamically and compiled into different assemblies as needed, it is not required that the entire project compile successfully in order to run and debug a page.By default, Visual Studio completely compiles Web site projects whenever you run or debug any page. This is done to identify compile-time errors anywhere in the site. However, a complete site build can significantly slow down the iterative development process, so it is generally recommended that you change the build project option to compile only the current page on run or debug.
Deployment	Because all class files are compiled into a single assembly, only that assembly needs to be deployed, along with the .aspx and .ascx files and other static content files.In this model, .aspx files are not compiled until they are run in the browser. However, when used with Web Deployment Projects (a downloadable add-in to Visual Studio 2005), the .aspx files can also be compiled and included in a single assembly for deployment.Each time you deploy the single assembly produced in this model, you replace the code for all pages in the project.	Both .aspx files and code-behind files can be compiled into assemblies using the Publish Website command in Visual Studio. (Note that the Build command does not create a deployable set of assemblies.) The updateable publish option supports compiling only code-behind files while leaving .aspx files unchanged for deployment.The default mode for precompiling produces several assemblies in the Bin folder, typically one per folder. The fixed-names option produces one assembly per page or user control and can be used to create deployable versions of individual pages. However, the fixed-names option increases the number of assemblies and can result in increased memory usage.
Upgrade from Visual Studio .NET 2003	Because the Web application project model is the same as in the Visual Studio .NET 2003, upgrade is generally simple and will usually not require any restructuring of the application.	The compilation option for Web site projects is significantly different than Visual Studio .NET 2003. A conversion wizard is available to upgrade existing Visual Studio .NET 2003 Web projects to Web site projects. For any reasonably complex Visual Studio .NET 2003 projects, manual fix-up is usually required after the conversion. For most scenarios, it is preferable to upgrade existing Visual Studio .NET 2003 projects to Web application projects in Visual Studio 2005.

[reference]

Basic strategy for an asp.net app performance

1. dispose of resources once they are no longer required. For example, use(resource object){…}
2. ensure connecting to a database is done in the best possible way (good to use “use” block).
3. using stored procedures can improve data access performance.
4. use generics to improve performance of collections to keep from unboxing.
5. minimize the session state to allow less processing to be done by ASP.NET.
6. disable view state to reduce the amount of data sent to and from the web server.