Anas Ghanem

When developing web application, you will need to decide which date selector you are going to use , you may choose between the Caledar Extendar , or any other 3'rd party controls (like infragistics ,Telerik ,...).In the future , if you decided to change the date selector for some reason , you will need to go to all places in which you used the date selector and change the code to use the new date selector control !

The required changes could be :

1. you will need to remove all "<%@ register  " tags that reference the old control
2. change the pages code behind to use the new control .
3. also you  may need to change the validations.

The Solution :

What I suggest here is that from the Beginning of the development , create a User Control that expose some properties like Selected Date(set , get) , and another property like IsRequired , and inside the user control , you can place any type of date selector control , then you just need to use this user control as a date selector in your web site , and when you want to change the date selector control , you just need to change the user control code .

Hope it helps

Anas Ghanem

The DotNetNuke  localization engine depends heavily on the "LocalResourceFile" property which is contained in "PortalModuleBase" class which is must be the base class for the UserCotrols that needs to be used as a controls for the  Module.

The "LocalresourceFile" property uses the following code to get the correct Localization file for the control ( the code based on  DNN 4.08.04)

Me.TemplateSourceDirectory & "/" & Services.Localization.Localization.LocalResourceDirectory & "/" & Me.ID

Note how the property value depends on the UserCotrol ID , this will cause the problem  when the UserCotrol used as a child UserCotrol in another UserCotrol , or when its dynamically loaded to a nother  UserCotrol (using the LoadControl method) . in both cases the "LocalResourceFile" property will returns incorrect resource file which prevent the DotNetNuke  from localizing the control .

Note that when dynamically loading the UserCotrol using LoadControl method , the UserCotrol Id will be null , and when we place the UserCotrol in another UserCotrol , the UserCotrol id will be the Instance Id , for example if the UserCotrol is "Products.ascx" , then its id will be Products1 or the id that is assigned to it by the developer.

To overcome all of the above issues , the solution is to modify the LocalResourceFile for the UserCotrol , this can be applied by creating a new "LocalResourceFile" property that shadows the Property of the PortalModuleBase control (since the property is not overridable ), and statically return the correct LocalResourceFile , the problem in this solution is that you need to apply it to every UserCotrol .

The other solution( and the best I think)  is to create a base UserCotrol class that inherits from PortalModuleBase and fix the LocalResourceFile like below :

public partial class BaseUserControl : DotNetNuke.Entities.Modules.PortalModuleBase
{
    // basicly this will fix the localization issue 
    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        string FileName = System.IO.Path.GetFileNameWithoutExtension(this.AppRelativeVirtualPath);
        if (this.ID != null)
            //this will fix it when its placed as a ChildUserControl 
            this.LocalResourceFile = this.LocalResourceFile.Replace(this.ID, FileName);
        else
            // this will fix it when its dynamically loaded using LoadControl method 
            this.LocalResourceFile = this.LocalResourceFile + FileName + ".ascx.resx";
    }
}

Now change your UserControls to inherit from BaseUserControl Instead of directly inheriting PortalModuleBase .

I can place that code in the PortalModuleBase directly , but I don't like the idea of modifying the Core DNN code , It will be nice if the DNN core team added that fix ).

I used that solution in my projects , Please Let me know if there is any issues in it.

Thanks

Anas Ghanem

The ListView Control Supports a lot of functionalities , one of those functionalities is the built in support for data paging .

You can implement data paging in ListView with a help of the  DataPager control.

The default behavior of the DataPager control is to provide paging functionality through PostBacks(like the GridView ) control , but the interesting thing is that the Pager Can Be configured to use the query string to keep the current displayed page , this behavior is very important if it used with the output cache to vary the page output Based on That query Field, this way you will have a separate cached version of the web page  for each ListView Page, so that you can Provide an Effective and scalable data paging solution ( for example like the "http://weblogs.asp.net" page ) .

To configure the DataPager control to use the querystring , you need to set its "QueryStringField" property to the query string paramter name that you want to use .

<asp:DataPager ID="DataPager1" runat="server" QueryStringField="PageNumber"....

Now the Pager control will add the page number to the querystring field in the page url , for example :

Default.aspx?PageNumber=1

Now you can vary the page outputcache based on the "PageNumber" query string field using output cache directive , in the page decalration :

<%@ OutputCache Duration="90" VaryByParam="PageNumber"  %>

This way you will have a separate cached version for each ListView page , and so your application will use the cached version for the subsequent requsts of the same ListViewPage.

You can also optimize this solution by turning off the ListView ViewState by setting its EnabeViewState property to false .

Anas Ghanem

  The ListView control is a new data presentation control that was added to .Net 3.5 , you may wonder why its added to the framework , and what it provide .

I believe the ListView control was added to provide The following functionalities :

1. A very flexible and customizable layout.
   
2. A built in data paging support with the DataPager control.
   
3. support data grouping ( repeating items) .
4. Built in support for deleting,inserting,paging,sorting,and updating the data.

Now , to compare the ListView control with the dataList,GridView and repeater control , lets look at the table below :

 The GridView : it supports paging but it doesn't provide a flexible layout , since its mainly used to display the data in a table based layout.And If we looked at data inserting , the Gridview doesn't have a built in support for inserting data( since it doesn't call the insert method of it underlying data source when you click on a button with a CommadName set to "Insert" ).

The DataList : it support data grouping ( through its RepeatColumns property) , but it doesn't have a built in support for paging,inserting ,deleting , updating the data. and if you looked at its laout , you will find that by default  the datalist renders as html table and you will have to set its flowLayout to "Flow" to stop that behaviour.

The Repeater control : you will find that it provides a flexible layout but it doesn't support data grouping ,inserting,deleting , updating  and paging through the data .

Summary :

The ListView control was added to provide a rich data control that can support all the required functionalities at the same time , so now you can easily display a fully customizable layout that supports Grouping,paging , inserting , deleting , updating and sorting the data.

Anas Ghanem