Some time ago I needed to render hierarchical data to a <ul>/<li> elements structure and also be able to render a special attribute to the <li> Html elements.

Using TreeView control I found no better way than re-implement the Render method, loosing the out-of-the-box binding process.

Since I want to have a control similar to TreeView with all its binding richness I decide to write a ListView control.

This is the typical declaration I want to achieve:

<NG:ListView ID="orderedlistView1" runat="server" DataSourceID="SiteMapDataSource1" Mode="Ordered">     <DataBindings>         < NG:ListNodeBinding DataMember="SiteMapNode" AttributeField="Url" TextField="Title" />         < NG:ListNodeBinding DataMember="SiteMapNode" AttributeField="Url" TextField="Url" Depth="1"/>         < NG:ListNodeBinding DataMember="SiteMapNode" AttributeField="Title" TextField="Title" Depth="2"/>     </DataBindings> </ NG:ListView>

It looks pretty familiar...

In ListView control you can set the Mode property to choose whether to render an ordered list (<ol>) or an unordered list (<ul>).

Using the ListNodeBinding you can also use the AttributeField property to specify aditional attributes to rendered in the <li> html element (ex: <li Url="my Url" >some text</li>).

Also, there's no hierarchy depth limit.

ListView Sample.zip (12.58 kb)

Before proceeding to the implementation details, let's discuss a little about how ASP.NET handles automatic Id generation.

First of all, the Control.UniqueID property is the key to all major ASP.NET benefits. In fact, ASP.NET gives us unique Id's for each control which give us a deterministic way of recreating page controls. Without this, Viewstate and Events were impossible to achieve.

ASP.NET also gives us the concept of naming controls, that enable us to easily find the correct control and to write more perceptible code, but More...

Some time ago, while developing a large corporate ASP.NET application with high complex layout requirements and thus, many custom composite controls, I was faced with the following problem:

The generated HTML of my pages don’t meet my bandwidth constrain of 50Kb/page, even after applying the traditional ways to reduce page size (compression, viewstate optimization). Looking carefully at the HTML source I found that a big amount of size has due to the large values 'id' and 'name' attributes. The sum of all this values could be up to 40% of page size, and this became a real issue to me.

So, ASP.NET gives us out of the box a unique strategy to generate the control's ID values. Although such strategy is most of time a satisfactory approach, there are cases when it can become problematic. More...

While searching a way to solve the HtmlControls tag mapping problem I found that the new SP1 bring an extra undocumented hotfix.

This undocumented hotfix changes MainTagNameToTypeMapper.GetControlType method so that, for every tag name regardless is kind, a tag type mapping is always performed.

This little change enables us to tag map HtmlControls the same way we map WebControls and UserControls. Here is an example: More...

Tag Mapping is not a new ASP.NET 2.0 feature, but only recently many people discover it.

<system.web>
  <pages>
    <tagMapping>
      <add tagType="System.Web.UI.WebControls.TextBox"
           mappedTagType="MyTextBox"/>
    </tagMapping>
</pages>

The use of Tag Mapping allow us to, at parsing time, replace a given control type with other control type. The only constrain is that new control type extends primary control type.

If I use Tag Mapping with Web Controls everything works fine but if, instead, I use Html Controls, like HtmlForm, with tag mapping no mapping is done.

Using Reflector I found no reason for this behavior.

From time to time the question strikes back: How to validate an Email?

If you think you know the answer then you must read this Phil Haack post.

This is a sample I made for a recent project. The tree is based on Moro script with a few changes and a major improvement: a tools menu that enables add and remove actions directly on node.

Beside the tools menu its now possible to:

• prevent a node from being dragged: drag:false
• prevent a node from being a drop target: drop:false
• prevent a node from being modified(keep structure intact): lock:true

• if the node.parent is locked(lock:true) then the node is not electable for drag or for remove and the tools menu is empty
• if the node is locked(lock:true) then isn't possible to add more nodes(either folder or file)

Remember this is just a concept proof, not a final release, but even so i believe it could be usefull.

MooTreeAdvanced.zip (67.92 kb)