Core :: WebControls

Introducing DNNMultiStateBox

Mon, 12 May 2008 06:00:00 GMT

One of the new features coming in Cambrian is an update in the permissions grid. The current grid supports two states, Allow and Null (not assigned). The new grid will support three states (Allow, Deny, and Null). The obvious question here is how do you present this to the user? The current design allows for a nice compact way to set the permissions within a grid utilizing checkboxes. The new way will use a new DotNetNuke WebControl that supports multiple states and mimics a checkbox. The original name I came up with for the control was DNNTriStateCheckbox. However, while developing this control I soon realized there was no reason I needed to only support 3 states and saw the opportunity to support any number of states and not necessarily look like a checkbox. So the control is now called DNNMultiStateBox. It is probably the simplest of all the controls in the

Wed, 14 Nov 2007 17:43:03 GMT

For a long time now many skinners for DotNetNuke have felt like customizing individual menu items was like looking for the Holy Grail. All the menus I have contributed to the community (Solpart and DNNMenu) have always had the ability to customize each menu item. The problem always was
how do we allow DotNetNuke the ability to customize the items? The only place the unique menu structure is known is after the portal is created, well out of reach of someone providing a generic skin to fit any site. Sure there are those portal admins out there that know enough about css to make it work, but there still was a problem in how to access each item directly in css.

I have been considering options for how to overcome this for some time now, and am currently working on the 2.0 version of the webcontrols which should contain one possible solution. However, those controls are far from complete so I decided to offer a minor hack along the same lines.

First, let us consider eclayf's idea from the forums, where I borrowed the name of this blog entry from. The idea is to loop through all menu items and assign a background image to each item based off of the icon assigned. This allows the background image to be customized by the portal admin.

To try this idea out add the following code to your ascx page using the DNNMenu (not solpart). I tested with default blue for DNN.

This should cause the icon images to be displayed as the background.

Note: I noticed that if your skin declares the background-color (as the default blue does), the hover will no longer display the background. If you change it to not set the background then the image remains.

While this works, it is far from ideal. For one thing the admin menu item icons are not customizeable. Probably the biggest shortcoming is you can only customize the image, which happens to meet eclayf's requirements, but not generic enough to implement for DotNetNuke.

The idea I have been toying with is allowing the next version of the menu to support known client-side IDs. My current thought is to allow the skin to decide whether to go this route by providing a "safe" known namespace. For example, in your skin you would have a property like ClientIDPrefix="jcompany", then on the client each node will be assigned a unique id, prefixed with that text. So the root would be jcompany__0, jcompany__1, etc. The child of
jcompany__2 would be jcompany__2_1, jcompany__2_2, etc. This way it would allow the skinner
to predefine as many levels as he/she sees fit, and as long as the user of the portal doesn't exceed the predefined number, the skin should work as originally intended. Even if the skinner doesn't provide the level necesssary (something like jcompany__2_2_1_3_5), there is nothing stopping the user from adding the css himself, perhaps copying the value from a class defined higher up. The only pitfal in this approach is the worry about overlapping prefixes with other controls on the page.

In order to try this concept out add the following code to you ascx file that uses the DNNMenu

Then in your css file add something like

#jcompany__0
{
	background: red;
}

#jcompany__1
{
	background: blue;
}

#jcompany__1_0 td
{
	background: green;
}

#jcompany__1_1 td
{
	background: orange;
}

Note: It is worth noting that in general it is a bad idea to change the ids of a any control, as it most likely will break the control when it does a lookup by its id. In the DNNMenu's case, those references to the lookup are cached internally, thus this reassignment of ids will work.

Right now this is just an idea I'm toying with. If people like the approach I probably will include it in version 2.0 of the DNNMenu. Any feedback on this would be welcome.

BETA TEST PROGRAM: ClientAPI/WebControls - DawnTreader and Caspian

Thu, 18 Oct 2007 22:10:23 GMT

The conversion of the ClientAPI and WebControls to utilize the MS AJAX Framework along with emitting xhtml compliant markup is near completion. It is now time to start testing the backwards compatibility of the conversion. In order to adequately do this, I am asking for the communities help. If you are a skinner who uses any of the DotNetNuke webcontrols (DNNMenu, DNNTreeView, etc.) your assistance is needed. If you are a module developer who uses any portion of the ClientAPI or any of the WebControls, you assistance is also needed.

Interested in ensuring that your investment in DotNetNuke is backwards compatible? Follow the instructions in this thread.

Capturing the OnSubmit Event

Tue, 21 Aug 2007 01:43:53 GMT

Sometimes I grow frustrated when trying to solve apparently simple things, that end up taking most of the day to come up with an answer. And if the answer is one that is bordering on a hack, I am even more distraught. This happened to me again while trying to optimize the latest version of the webcontrols, that will now use the Microsoft AJAX extensions framework. The optimization deals with allowing the control to persist its current structure. For example, when you have a tree that supports populate on demand, and you expand a node, causing a callback to occur, the new structure should be persisted. When a postback occurs, the tree should remember its structure (including what nodes are expanded). The code for this was already done. It was being called with each node expand, and each node selection. A more optimal way to handle this would be to simply call this persistence logic just before submitting the page. Simple, right?

Uh, no actually. If you simply place an event handler on the form's onsubmit, you will only get notified when a submit button is pressed. You will miss all other postbacks (like an autopostback from a dropdownlist). Knowing the MS AJAX framework has a nice object and event model I expected to find an event exposed. This search yielded no results, so I decided to have a look at what the Control Toolkit does. There are two controls that need this same notification: TextBoxWatermark and ConfirmButton. The solution offered there was not as good as I'd hoped. The way these controls handle getting the event notification is as follows

1) Register the WebForm_OnSubmit event on the server with the following code

ScriptManager.RegisterOnSubmitStatement(this,typeof(ConfirmButtonExtender),"ConfirmButtonExtenderOnSubmit","null;");
ScriptManager.RegisterOnSubmitStatement(this,typeof(TextBoxWatermarkExtender),"TextBoxWatermarkExtenderOnSubmit","null;");

2a) When the control initializes on the client, the logic looks for the js function name that the ASP.NET runtime registers on the client. Note that neither registration method invokes a specific function (null as the last parameter)

function WebForm_OnSubmit() {
//Note:  other page logic may register additional functions here as well!
null;
return true;
}

2b) A check to verify that a previous onsubmit handler was not already registered. Note, this is done with a shared/static property (not on the instance).

if ((typeof(WebForm_OnSubmit) == 'function') && !AjaxControlToolkit.TextBoxWatermarkBehavior._originalWebForm_OnSubmit) {

3) Assign the previous onsubmit handler for the watermark shared/static property to the current onsubmit handler

AjaxControlToolkit.TextBoxWatermarkBehavior._originalWebForm_OnSubmit = WebForm_OnSubmit;

4) Assign a new function reference to the existing handler.

WebForm_OnSubmit = AjaxControlToolkit.TextBoxWatermarkBehavior.WebForm_OnSubmit;

5) The shared/static method that was reassigned to WebForm_OnSubmit will first invoke the original onsubmit method, if it returns successfully it will then loop through all components/extenders currently registered, and if it is of the same type as the current one, invoke that instance's onsubmit handler

AjaxControlToolkit.TextBoxWatermarkBehavior.WebForm_OnSubmit = function() {
  var result = AjaxControlToolkit.TextBoxWatermarkBehavior._originalWebForm_OnSubmit();
  if (result) {
    var components = Sys.Application.getComponents();
    for(var i = 0 ; i < components.length ; i++) {
      var component = components[i];
      if (AjaxControlToolkit.TextBoxWatermarkBehavior.isInstanceOfType(component)) {
        component._onSubmit();
      }
    }
  }
  return result;
}

At first I did not think that this logic would work, as I felt that it would loose the onsubmit events of any other code that utilized the RegisterOnSubmitStatement. However, after further review, I now see that it should work fine, as it is kind of like a linked list approach.

Issues
The first of three issues I have with this is similar to my issue with how the toolkit makes assumptions about what ASP.NET generated javascript names will be, in the earlier case it was the assumption on the function named WebForm_DoCallback, in this case it is WebForm_OnSubmit. While I do not anticipate MS changing the names of these functions, it certainly is not a dependency I would willingly keep unless necessary, as it could break going forward.

The second issue is in how there is no global handler inside the toolkit for this logic. Rather it is up to each control to rewrite this somewhat clunky functionality.

The last issue lies in an additional dependency the ConfirmButton places on the TextBoxWatermark. Apparently, if a watermark and confirm button exist on the same page, the watermark's handler needs to execute first. Obviously, this has a major issue for anyone else wishing to implement similar logic, as the confirm button will need to be reworked for each of these controls.

Different Approach
Not willing to live with this set of shortcomings, I decided to look for other approaches. Unfortunately, I found none, so I decided to code my own. What I came up with is a new component called submitComponent, that lives in the dnn.controls client-side namespace. The following is how it works

1) The server-side logic needs to register the componentbr

RegisterSubmitComponent(Me.Page)

This in turn add the following to the WebForm_OnSubmit function generated to the client

function WebForm_OnSubmit() {
//Note:  other page logic may register additional functions here as well!
dnn.controls.submitComp.onsubmit();
return true;
}

2) The client-side dnn.controls script will instantiate the dnn.controls._submitComponent component, inheriting from Sys.Component. Inheriting from Sys.Component gives our new class the event handler logic we are looking for (getHandler, addHandler, removeHandler).

3) The control's script will add a handler for onsubmit, by calling the submitComponent's add_handler method

this._onsubmitDelegate = Function.createDelegate(this, this._onsubmit);
dnn.controls.submitComp.add_handler(this._onsubmitDelegate);

This approach does not have issue 1 listed above, as it does not hardcode the WebForm_OnSubmit method into the client-script, rather it uses the ASP.NET functionality as intended by registering the script to execute onsubmit. The second issue is addressed as there is now a global component that can be used by each of my controls. The last issue is not addressed by my component since I have no such requirements. However, the component could easily add an additional parameter to the add_handler method to specify it must execute last.

I can't help but think that this logic is already implemented somewhere and I have missed it. If anyone out there knows how to better handle this scenario please post a comment./p>

Navigation Provider Custom Attributes - A Sneak Peak At 4.5.0

Fri, 02 Mar 2007 18:00:00 GMT

DotNetNuke has supported navigation providers for about a year and a half. Currently there are 4 providers we support. The provider model is based off of interfaces, promoting a one-size-fits-all mentality. This can be both a blessing and a curse. The curse as it relates to the navigation providers is that it limits the features that the navigation provider's control can support. For example, recently I added support for the DNNMenu to support horizontal submenus. In order for this feature to be used in a skin (using the navigation provider), it needs a property exposed. Adding this property, would expose it to all providers, which of course makes little sense for something like a treeview. 4.5 will no have the ability to specify custom attributes to the navigation providers. This can be accomplished by adding the following to the skin's ascx file.

The following directive needs to be added at the top

<%@ Register TagPrefix="dnn" Namespace="DotNetNuke.UI.Skins" Assembly="DotNetNuke" %>

Then within your skin object you simply embed a CustomAttributes element, then specify one or more attributes.

If you interested in how the skin object was modified, keep reading.

This is accomplished by adding a Generics collection to the NavObjectBase (which is used by the Nav.ascx skin object).

    _
    Public ReadOnly Property CustomAttributes() As Generic.List(Of CustomAttribute)
      Get
        Return m_objCustomAttributes
      End Get
    End Property

The provider will then be able to enumerate these custom attributes and apply them to the underlying control.

      For Each objAttr As DotNetNuke.UI.Skins.CustomAttribute In Me.CustomAttributes
        Select Case objAttr.Name.ToLower
          Case "submenuorientation"
            Me.Menu.SubMenuOrientation = DirectCast(System.Enum.Parse(Me.Menu.SubMenuOrientation.GetType, objAttr.Value), DotNetNuke.UI.WebControls.Orientation)

End Select
Next

Edit In Place Enhancements - A Sneak Peak At 4.5.0

Fri, 02 Mar 2007 17:01:00 GMT

Thought I'd mention that the Edit In Place enhancements will be incorperated into 4.5.

Instead of rewriting an entire entry, I think it is best to simply point you to the original blog, which also links the document with all the design details.

Researching MS AJAX: ScriptControlBase and Callbacks

Wed, 14 Feb 2007 01:00:00 GMT

Yesturday I blogged on the MS AJAX framework's PageMethod implementation falling short when it comes to control developers. Before I completely gave up on this, I decided to investigate some of the toolkit's controls to see how they handle these callbacks. Two controls came up in my search: Rating and ReorderList. I spent some time investigating the Rating control, which seems to utilize the classic ASP.NET 2.0 callback mechanism. The only issue I saw is that the control did not use the script returned to it by the GetCallbackEventReference method, rather it had hardcoded its call into its js file. While I don't anticipate that Microsoft will ever change this function declaration, I wouldn't want to bet on it. The method I am referring to is WebForm_DoCallback. I decided to search the entire toolkit for any other controls utilizing this approach. I didn't find any other controls but I did find a script called BaseScripts which really peaked my interest.

_invoke : function(name, args, cb) {
    /// invokes a callback method on the server controlif (!this._callbackTarget) {

Seeing that this method is private, or at least meant to be since it is prefixed with an underscore, I tried to find where it is called from. I had found nothing. Perhaps it was only a partial implementation. I decided not to give up, rather, I did another search to see how a control's _callbackTarget property could be set. This search yielded this code in the ScriptObjectBuilder class

// determine if we should describe methods
foreach (MethodInfo method in instance.GetType().GetMethods(
  BindingFlags.Instance | BindingFlags.Static | BindingFlags.Public))
{
    ExtenderControlMethodAttribute methAttr = 
      (ExtenderControlMethodAttribute)Attribute.GetCustomAttribute(
        method, typeof(ExtenderControlMethodAttribute));
    if (methAttr == null || !methAttr.IsScriptMethod)
    {
        continue;
    }

    // We only need to support emitting the callback target and registering  
    //the WebForms.js script if there is at least one valid method
    Control control = instance as Control;
    if (control != null)
    {
        // Force WebForms.js
        control.Page.ClientScript.GetCallbackEventReference(control, null, null, null);

        // Add the callback target
        descriptor.AddProperty("_callbackTarget", control.UniqueID);
    }
    break;
}

This was very interesting to me, for it seems that if we denote an internal method as being a ScriptMethod and as long as the method is public, static, or an instance method we are going to be "hooked up".
Note: It seems odd that this is an or... looks like a bug. I would not assume you can have a private instance method and it still work.

I decided to make a simple control to try out this seemingly undocumented functionality.

My control was very simple. It inherits from the ScriptControlBase class, renders simple div tag with text, and has two methods marked as ExtenderControlMethod.

using System.Web.UI;
using System.ComponentModel;
using AjaxControlToolkit;

[assembly: WebResource("MyAjaxControls.SimpleCallback.SimpleCallback.js", 
    "application/x-javascript")]
namespace MyAjaxControls
{
    [ClientScriptResource("MyAjaxControls.SimpleCallback", 
      "MyAjaxControls.SimpleCallback.SimpleCallback.js")]
    public class SimpleCallback : ScriptControlBase
    {
        public SimpleCallback()
            : base(false) {}

        [DefaultValue("")]
        [Category("Appearance")]
        public string Text
        {
            get { return (string)(ViewState["Text"] ?? string.Empty); }
            set { ViewState["Text"] = value; }
        }

        protected override void Render(HtmlTextWriter writer)
        {
            writer.AddAttribute(HtmlTextWriterAttribute.Id, ClientID);
            writer.RenderBeginTag(HtmlTextWriterTag.Div);
            writer.Write(this.Text); 
            writer.RenderEndTag();
	//required to hook up element on client
            ScriptManager.RegisterScriptDescriptors(this); 
        }

        [ExtenderControlMethod]
        public string HelloWorld(string s)
        {
            return "hello: " + s;
        }

        [ExtenderControlMethod]
        public int Add(int x, int y)
        {
            return x + y;
        }
    }
}

The client side library was also simple. It simply hooked up the click event of the element and invoked our callback

Type.registerNamespace("MyAjaxControls");

MyAjaxControls.SimpleCallback = function(element) {
    MyAjaxControls.SimpleCallback.initializeBase(this, [element]);    
    this._onclick$delegate = Function.createDelegate(this, this._onclick);
    this._cbcomplete$delegate = Function.createDelegate(this, this._cbcomplete);
}
MyAjaxControls.SimpleCallback.prototype = {
    
    initialize : function() {
        MyAjaxControls.SimpleCallback.callBaseMethod(this, "initialize");
        var element = this.get_element();
        $addHandler(element, "click", this._onclick$delegate);
    },

    dispose : function() {

        var element = this.get_element();
        if(element) {
            $removeHandler(element, 'click', this._onclick$delegate);
        }
        MyAjaxControls.SimpleCallback.callBaseMethod(this, "dispose");
        
    },
    
    _onclick : function(sender, e) {
        //this._invoke('HelloWorld', ['hi'], this._cbcomplete$delegate);
        this._invoke('Add', [20, 3], this._cbcomplete$delegate);
    },
    
    _cbcomplete: function(result, ctx)
    {
        alert(result);
    }
}

MyAjaxControls.SimpleCallback.registerClass("MyAjaxControls.SimpleCallback", AjaxControlToolkit.ControlBase);

I must say that I am really pleased to find this implementation. Even though under the covers it is using a classic ASP.NET 2.0 callback, all the plumbing work to allow our multiple parameters along with any number of functions to be invoked is all handled for us. I am not sure why the _invoke is private, or if this is even functionality that should be used by control developers. Searching the internet was not helpful at all. The only reference I found on the subject is this blog.

ScriptControlBase implements some great new features that hopefully soon will make their way into ExtenderControlBase before the next real release. These include:

Load/Save ClientState methods similar to Load/Save ViewState on the server and client-side
ASP.NET 2.0 Callbacks
ScriptUserControl to create custom AJAX controls using .ascx files. Facilitates creating reusable mashup controls when building web applications
ControlBase.prototype.findElement() client method to find child objects using .NET Naming Containers (ScriptControlBase is an INamingContainer)

If anyone out there can shed some light on this functionality I would really appreciate it.

Researching MS AJAX: PageMethods

Tue, 13 Feb 2007 01:00:00 GMT

With my plate relatively clear, I have decided to spend some time investigating the released version of Microsoft AJAX Extensions for ASP.NET 2.0 (formarly Atlas and from now on I will call it MS AJAX). Specifically, I want to see what advantages and disadvantages I would have by utilizing this framework instead of (or addition to) the ClientAPI. One of the first things that I looked for was the ability to make "callbacks". I had heard about Atlas' ability to invoke webservices for some time now and have been on a project that was IE specific and therefore was able to use the WebService behavior to accomplish the same thing. While this functionality is cool, people who know me, know that my real passion is for writing reusable webcontrols. Writing a webcontrol that needs to communicate with the server

Should not require the end user to expose a webservice.
Communication to the server should allow the control be able to raise events in the context of the current page.

In my opinion, these two requirements are vital to writing webcontrols.

My initial look through the documentation I found little that would assist me in the answer (eventually I found this last sample). Searching google yielded some promising results. Apparently, there is this concept called PageMethods that appeared to be able to make a callback from the client to the server without the need for a separate webservice. After digging through several sites explaining their use and lack of documentation I soon learned that through the various releases of this feature, quite a few changes were made. Two of these changes are the need to also decorate your method with a ScriptMethod attribute (though when I try it, this does not seem necessary any more), and the fact that in the later betas these methods are now required to be static!

It appears that PageMethods will satisfy my first requirement (not needing external webservices), however, the second is not met. For we need the context of the current page to be useful. To understand what I mean, lets take the DNNLabelEdit control. A developer can place this on any page or module (for DNN), handle an event (UpdateLabel) and successfully have access to all it needs to update the database (ModuleId for example). If we don't have the context of the page, we will need the information posted to the server through the callback. The control cannot make assumptions on what should and shouldn't be posted, so this leaves it up to the developer.

One of the reasons for the change in requiring static/shared methods is stated here
"They reason the AJAX team decided to make these methods static was so you could avoid page-lifecycle issues and subtleties, such as the inability to modify or access page state"

ASP.NET 2.0 out of the box supports callbacks. These same issues are present, yet they still support the feature! I know, for I have researched and documented them when dealing with the DNNTabStrip control. I suppose I am not as upset as I could be, especialy if I had tried to adopt Atlas earlier and had developed solutions requiring this functionality like others have commented in the blogs listed above. It is looking like I will be continuing the use of the ClientAPI's callback functionality. Note: I could choose to use the ASP.NET 2.0 callback functionality, but I don't think it worth moving, since my callback implementation has a few more enhancments included.

Some people have questioned why even bother with PageMethods if they have to be static. They argue they are just like webservices. The fact that they appear to satisfy my first requirement makes them different.

Two final notes before moving on.

First, I am readily admitting that I just started researching MS AJAX, and therefore may not have all my facts straight. If someone knows another way that MS AJAX solves my requirements above, please comment or send me an email.

Finally, I see many people who decide to use PageMethods do so by setting the ScriptManager's EnablePageMethods property to true. I would highly recommend against this. While it makes your invoking of the method simple, it generates a large amount of payload sent down to the client. To see what I mean, I am listing the output generated within the page for only two simple methods (Add and Add2)

if (value < 0) { throw Error.argumentOutOfRange('value', value, Sys.Res.invalidTimeout); }
PageMethods._staticInstance._timeout = value; }
PageMethods.get_timeout = function() {
return PageMethods._staticInstance._timeout; }
PageMethods.set_defaultUserContext = function(value) {
PageMethods._staticInstance._userContext = value; }
PageMethods.get_defaultUserContext = function() {
return PageMethods._staticInstance._userContext; }
PageMethods.set_defaultSucceededCallback = function(value) {
var e = Function._validateParams(arguments, [{name: 'defaultSucceededCallback', type: Function}]); if (e) throw e;

PageMethods._staticInstance._succeeded = value; }
PageMethods.get_defaultSucceededCallback = function() {
return PageMethods._staticInstance._succeeded; }
PageMethods.set_defaultFailedCallback = function(value) {
var e = Function._validateParams(arguments, [{name: 'defaultFailedCallback', type: Function}]); if (e) throw e;

PageMethods._staticInstance._failed = value; }
PageMethods.get_defaultFailedCallback = function() {
return PageMethods._staticInstance._failed; }
PageMethods.set_path("/MSAjax10/PageMethods.aspx");
PageMethods.Add= function(x,y,onSuccess,onFailed,userContext) {PageMethods._staticInstance.Add(x,y,onSuccess,onFailed,userContext); }
PageMethods.Add2= function(x,y,onSuccess,onFailed,userContext) {PageMethods._staticInstance.Add2(x,y,onSuccess,onFailed,userContext); }

While it is nice to be able to invoke these methods like

PageMethods.Add(1,2, methodComplete, methodError);

The amount of overhead for each page request is not worth it IMO.

Instead I recommend calling the method like this

Sys.Net.WebServiceProxy.invoke('/MSAjax10/PageMethods.aspx', 'Add', false, { x:1, y:2 }, methodComplete, methodError);

DotNetNuke WebControls v1.5 Released

Fri, 09 Feb 2007 01:00:00 GMT

I am pleased to announce the release of the latest DotNetNuke WebControls v1.5. I must admit, this release took a lot longer than I had anticipated. I have spent the last couple weeks putting everything else on hold in order to finish up the DNNTabStrip control. Most of the work done will be visible to the public, however, there is quite a bit of work that I spent in prototyping that may never see the light of day.

The bulk of the work was done in the DNNTabStrip control. This required some additional changes to the ClientAPI. See the note below on the installation of the controls if you plan on using the advanced features in the DNNTabStrip.

ClientAPI Enhancements / Bug Fixes
ClientAPI - Dynamic Script Loading - Removed reliance on setScriptLoaded. Support for Safari through XMLHTTP request.
ClientAPI - Dynamic Batch Script Loading

WebControl Enhancements / Bug Fixes
DNNTabStrip - Support for CallBackType=ProcessPage (WCT-5015)
DNNTabStrip - Support for script registration from containing tab's controls (WCT-5016)

DNNMenu - Support for Horizontal SubMenus (WCT-5017)
DNNMenu - Default MouseOutDelay to 500 ms. Only render to client when different (WCT-5018)
DNNMenu - Fixed bug with IE, where if you clicked menuitem with target=_blank, then went back to the menu, the click events wouldn't fire (WCT-5019)

DNNLabelEdit - Added option to Render as a div tag instead of span. This is for scenarios where you wish to have block elements (P, INPUT, etc.) inside your editing control, which is an inline element (span). Striving to support XHTML compliance. (WCT-5020)

New and Updated Samples
New sample - showing DNNMenu with Horizontal SubMenus
New sample - demonstrating TabStrip Alignment
New sample - demonstrating TabStrip's capabilities to contain complex controls and still utilize callbacks.
Updated sample - Dynamic Script Loading to include dynamic batch loading
Updated sample - DNNMenu to include option for Horizontal SubMenus
Updated sample - DNNLabelEdit to include option to render as div

Version Support
I have added an additional install file (DotNetNuke_WebControls1.5.0_Install_11.zip) that will allow version 1.5 of the WebControls to work with ASP.NET 1.x (DNN 3.x). The additional files included in this zip are ClientAPI files. These include the DotNetNuke.WebUtility.dll, and all js files that are not controls. Depending on the DNN version of 4.x you are updating, you may need some the files as well. For example, if you plan on using the new tabstrip or edit in place functionality, the js files from this update will be required prior to 4.5 (dnn.js, dnn.scripts.js).

I also wanted to say that this this is perhaps the last version that I will be supporting v1.x of the .NET Framework. There are several reasons for this that I may go into more detail in future blogs.

DNNMenu - Horizontal SubMenus
One of the enhancements listed above is horizontal submenu support. This has been a highly requested item for a long time. While this release will allow the DNNMenu to contain horizontal submenus, it does not address how you as a skinner can set this property. Look for a blog in the near future explaining an enhancement to the core skin objects to enable this.

View Live Sample Site and Download
You can view all the samples online along with downloading all the source and installation files from http://webcontrols.dotnetnuke.com

Questions
Currently there is no WebControls forum. Therefore if you have any questions it is best to post them in the ClientAPI forums.

TabStrip Rendering Document Complete

Sun, 04 Feb 2007 20:00:00 GMT

The DNNTabStrip control has been under development for quite some time. The original document was written in August of 2006. I am happy to announce that I was able to finish the final chapter for it just a couple hours before the Super Bowl (Go Bears!). Chapter 6 deals with the two callback methods available, detailing under what situations you would choose one over the other. Here is the introduction.

The ClientAPI currently supports two different types of Callbacks: Simple and ProcessPage. The difference between these lies in how much of the default ASP.NET page’s lifecycle is run before it is short-circuited. The following diagrams illustrate the differences.

For a CallbackType of Simple the grayed out boxes are skipped.

For a CallbackType of ProcessPage, all the same events that happen in a normal PostBack occur. The difference is in how much information is processed. For example, only the tab’s HTML is rendered.

You can read the document in its entirety here.

Please note that the code discussed in this document along with the samples have not been published or released yet.