If you are like me and want your websites to have a clean, unblemished look, then most likely you have either turned off the Print functionality in your DotNetNuke module settings or just use containers that don’t display the icon. While this does make the site look cleaner, it also takes away the functionality. I gave this some thought and concluded that a Widget would be a great way to provide the functionality for printing the content of modules on a page. I envisioned a selector that the user would click on that would allow them to print the content for a single module. A skin designer could embed the Widget directly into the skin, or a site administrator could selectively add it to pages using an HTML module.

Module Print Widget

A couple hours of hacking later I present to you the ModulePrintWidget for DotNetNuke. It’s simple and easy to use. When added to a page, it creates a drop-down list of each module on the page. A user can select a module from the list to see a preview, then click a Print icon to print the contents of that module. Here’s a short 45-second YouTube video that demonstrates the Widget in action: TechBubble ModulePrintWidget

You can download the Widget package at the link below (install as Superuser from the Extensions page):

You can also see a live demo of the ModulePrintWidget.

To use the Widget, add the following HTML so that it appears once on a page. You can add the markup anywhere that HTML is supported (module, skin, skin object, container):

<object id="MyWidget" codetype="dotnetnuke/client" codebase="TechBubble.Widgets.ModulePrintWidget"></object>

If you want to customize the appearance and language, use the optional parameters:

<object id="MyWidget" codetype="dotnetnuke/client" codebase="TechBubble.Widgets.ModulePrintWidget">
 <param name="selectorCssClass" value="Class-to-style-dropdown" />
 <param name="selectText" value="Default-text-for-dropdown" />
</object>

WidgetsThis is Part 2 of my four-part series on DotNetNuke Widgets. In Part 1 of the series, I covered some fundamental concepts related to DotNetNuke Widgets. In this post, I will introduce you to a few of the Widgets that are included with the DotNetNuke distribution. Before getting started I’d like to make one observation…these widgets were created prior to the inclusion of jQuery within the DotNetNuke Core. While the Widgets are production-ready, they could use some refactoring to take advantage of jQuery’s efficient engine for selecting and manipulating DOM elements.

All Widgets follow the same format for embedding in any extension (module, skin, skin object, container)

<object codebase="{WidgetType}" codetype="dotnetnuke/client" id="{WidgetId}">
	<param name="{WidgetParameterName}" value="{WidgetParameterValue}" />
</object>

{WidgetType} (required) = fully qualified Type name of the Widget
{WidgetId} (required) = arbitrary ID for the Widget’s DOM element (must be unique on the page)

A Widget can have zero or more child elements, each with a “name” and “value” attribute with corresponding {WidgetParameterName} and {WidgetParameterValue} values. Widget parameter names are case-insensitive. Widget parameter values are always case-sensitive.

StyleScrubberWidget

The purpose of this Widget is to “scrub” the appearance of a DotNetNuke page by removing undesirable attributes from specific elements on the page. For example, you may have a module that has a hard-coded “style” or “width” attribute that is disrupting the appearance of a page. You don’t really want to change the source code for the module (if it’s available) and you really want to use the module. This is where StyleScrubber Widget comes to the rescue. It enumerates a series of rules you provide and removes the undesirable attributes allowing elements to be fully styled with CSS. This Widget may appear any number of times on a page.

Parameters

classNames (required) – A list of class names separated by semi-colons. The Widget will only act on elements with a matching “class” attribute. At least one value must be specified. Example: head; normal; topic

tag (optional) – A HTML element tag name which acts as a filter in selecting elements. The default value is * which implies all elements. Example: div

removeAttribute (optional) – The name of the attribute which should be stripped from all elements that match the classNames and tag conditions. The removeAttribute parameter may be repeated multiple times to specify more than one attribute that should be removed. Example: style (strips the “style” attribute)

recursive (optional) – Value of true or false to indicate if the scrubbing cascades indiscriminately through all child elements of a matched element. Default is false.

Example

Remove all “width” and “style” attributes from TABLE elements that have a class value of “Normal” or “NormalBold”

<object codebase="StyleScrubberWidget" codetype="dotnetnuke/client" id="ScrubTable">
	<param name="classNames" value="Normal;NormalBold" />
	<param name="tag" value="table" />
	<param name="removeAttribute" value="width" />
	<param name="removeAttribute" value="style" />
</object>
RelocationWidget

The purpose of this Widget is to move or “relocate” content so that they visual location of the content differs from the physical location of the content in the page. The primary use-case is SEO. Using the RelocationWidget it is possible to have content as close to the top of the page as possible while moving the navigation lower down on the page. Since search bots do not run scripts, this arrangement is optimal for them. Users with script-enabled browsers will see the navigation in its intended location. This Widget may appear any number of times on a page.

Parameters

sourceId (required) – ID of the DOM element that contains the HTML content that will be relocated. It is recommended that you apply a CSS style of “display:none” to this element so it is not initially visible in the user’s browser.

targetId (required) – ID of the DOM element where the HTML content from the sourceId element will be moved. It is recommended that you apply a CSS style for “width” and “height” matching the dimensions that the relocated content will occupy. Doing so prevents other elements on the page from visually moving around when the Widget performs its action.

Example

Move all content from element “NavTemp” to “Nav”

<object codebase="RelocationWidget" codetype="dotnetnuke/client" id="MoveIt">
	<param name="sourceId" value="NavTemp" />
	<param name="targetId" value="Nav" />
</object>
RotatorWidget

Changes content within an element at a pre-defined interval. The content can be sourced from a location on the page, an RSS feed or sequentially numbered images. This widget is ideal for scenarios in which the content to be rotated is not known ahead of time and no interactivity is desired from the end-user. This Widget may appear any number of times on a page.

Parameters

elementId (required) – ID of the DOM element where the rotating content will be rendered.

height (required) – Height of the rotated content in pixels.

width (required) – Width of the rotated content in pixels

interval (optional) – Time interval in milliseconds for content rotation. Default is 2500 milliseconds.

direction (optional) – Direction in which new content slides. Values are UP, DOWN, RIGHT, LEFT (default), BLEND

transition (optional, experimental) – Transition effect for new content. Values are SLIDE, SNAP (default)

The RotatorWidget can rotate content from three sources. Content from all the sources is aggregated, then displayed so you can combine multiple sources in the same RotatorWidget instance if desired.

RSS Feed Source

feedUrl (required for RSS feeds) - URL of the RSS 2.0 feed from which content will be sourced

feedAttribute (required for RSS feeds) - Name of the element that contains the content to be rotated. Yahoo Pipes is used to retrieve the feed.

Sequential Image Source

imageUrl (required for images) – The base URL where the images to be rotated are located. Must end in slash (“/”).

imageTemplate (required for images) – The file name template for each image. The token {INDEX} may be used to indicate where the sequence number will be injected. The sequence begins at 1. Example: portrait{INDEX}.jpg for images names portrait1.jpg, portrait2.jpg, portrait3.jpg etc.

imageCount (required for images) – The number of images available for rotation.

imageScale (optional) – Indicates if images should be scaled by width or by height. Values are WIDTH and HEIGHT or blank (default) for no scaling.

Page Content Source

contentElementId (required for content) – ID of the DOM element that contains the content to be rotated. The Widget expects the DOM element to have zero or more child elements. The content of each child element is treated as a separate rotation item. Example: A <UL> element with multiple <LI> elements where each <LI> element contains one item of content.

Example

Rotate 10 images stored in a folder at an interval of 5 seconds.

&lt;object codebase=&quot;RotatorWidget&quot; codetype=&quot;dotnetnuke/client&quot; id=&quot;Animate&quot;&gt;
	&lt;param name=&quot;elementId&quot; value=&quot;PageHeader&quot; /&gt;
	&lt;param name=&quot;height&quot; value=&quot;100&quot; /&gt;
	&lt;param name=&quot;width&quot; value=&quot;400&quot; /&gt;
	&lt;param name=&quot;interval&quot; value=&quot;5000&quot; /&gt;
	&lt;param name=&quot;imageUrl&quot; value=&quot;/Portals/0/HeaderImages/&quot; /&gt;
	&lt;param name=&quot;imageTemplate&quot; value=&quot;header{INDEX}.png&quot; /&gt;
	&lt;param name=&quot;imageCount&quot; value=&quot;10&quot; /&gt;
&lt;/object&gt;
StyleSheetWidget

The purpose of this Widget is to provide a user interface that enables users to switch stylesheets in order to customize their browsing experience. This Widget may appear any number of times on a page.

Parameters

template (required) – The StyleSheetWidget renders an interface element for each stylesheet that the user can select from. The template parameter is used to specify the HTML markup that will be rendered for each stylesheet in the set. The HTML markup must be encoded and can use the tokens {TEXT} (replaced with the name of each stylesheet as specified in other parameters), {ID} (replaced with a unique identifier for each interface element that is rendered) and {CLASS} (replaced with “class” attribute and value). Example: <div title=”{TEXT}” {ID} {CLASS}></div>

default (required) – The value of the stylesheet that should be selected by default.

baseUrl (required) – The URL where the stylesheets are located.

cssClass (required) – The CSS class value to be used on interface elements corresponding to a stylesheet that is not selected.

selectedCssClass (required) – The CSS class value to be used on the interface element corresponding to the selected stylesheet.

In addition to the above, one parameter (name and value) is required for each stylesheet. The “name” attribute should contain the stylesheet filename and the “value” attribute should contain the human-friendly label associated with the stylesheet.

Example

Allow the user to select from five different color palettes.

&lt;object codebase=&quot;StyleSheetWidget&quot; codetype=&quot;dotnetnuke/client&quot; id=&quot;ColorSelector&quot;&gt;
	&lt;param name=&quot;template&quot; value=&quot;&amp;lt;div title=&quot;{TEXT}&quot; {ID} {CLASS}&amp;gt;&amp;lt;/div&amp;gt;&quot; /&gt;
	&lt;param name=&quot;default&quot; value=&quot;blue&quot; /&gt;
	&lt;param name=&quot;baseUrl&quot; value=&quot;&lt;%= SkinPath %&gt;css/&quot; /&gt;
	&lt;param name=&quot;cssClass&quot; value=&quot;Icon&quot; /&gt;
	&lt;param name=&quot;selectedCssClass&quot; value=&quot;Icon-Selected&quot; /&gt;
	&lt;param name=&quot;red&quot; value=&quot;Fire-engine Red&quot; /&gt;
	&lt;param name=&quot;blue&quot; value=&quot;Midnight Blue&quot; /&gt;
	&lt;param name=&quot;yellow&quot; value=&quot;Sunflower Yellow&quot; /&gt;
&lt;/object&gt;
EmbedWidget

This Widget is somewhat unique in that its purpose is to provide a standard way for embedding any embeddable content from other websites. Using this Widget, you create a “snippet” for any such content once using whatever unique requirements the source site may have. Once the snippet is created, you can then use the embeddable content multiple times within DotNetNuke using the standard Widget embedding syntax.

Parameters

publisher (required for user content) – This parameter tells the EmbedWidget where to look for the embeddable content. If it is not specified, the Widget looks for content in the folder “~/Resources/Widgets/DNN/EmbedWidgetResources/{type parameter value}/” If this parameter is specified, the Widget looks for content in the folder “~/Resources/Widgets/User/{publisher parameter value}/EmbedWidgetResources/{type parameter value}/”

type (required) – The type of content to embed. This value must correspond to a file named “{lowercase type parameter value}.snippet.htm” in the folder location specified above. The file must be a plain-text file containing solely the HTML markup necessary for rendering the content.

In addition to the above parameters, you can specify and arbitrary number of name/value parameters that are passed to the content snippet file when the content is rendered by the Widget. The value may be a single value or multiple values concatenated using a delimiter character. The default delimiter is “;”. You can overrride the delimiter by specifying the “multiValueDelimiter” parameter described below. Review the individual snippet file for each type of embeddable content for supported parameters specific to that content type.

multiValueDelimiter (optional) – Character used to delimit multi-value parameters.

When the Widget is rendered, the snippet file is parsed and token substitution is performed using values specified in the parameters. The syntax for tokens is:

{ parameter name : token template : default template }

For each token, the Widget checks to see if a corresponding named parameter is available. If so, it replaces the token with the token template otherwise it uses the default template. In order to substitute parameter values in the token template, placeholders are used. Placeholders are numeric and in the format {0}, {1}, {2} etc. The Widget substitutes values in the order they are specified.

For example: { width : width=”{0}” : width=”500″ } OR { coordinates : x={0},y={1} : x=100,y=100 }

Example

Embed a Flickr slideshow

&lt;object codebase=&quot;EmbedWidget&quot; codetype=&quot;dotnetnuke/client&quot; id=&quot;Flickr&quot;&gt;
	&lt;param name=&quot;type&quot; value=&quot;Flickr&quot; /&gt;
&lt;/object&gt;
VisibilityWidget

The purpose of this Widget is to enable an HTML element on a page to toggle the visibility of a container element located elsewhere on the page. The Widget included with DotNetNuke is now deprecated. Joe Brinkman has updated the Widget’s code and the updated one will be available in a future DotNetNuke release. You can read all about Joe’s enhancements in his blog post DotNetNuke Tips and Tricks #15: DotNetNuke Visibility Widget.

Some years ago, I had presented a solution for dynamically loading a skin layout based on the user’s browser type. Fast-forward to the present — at the Fall 2009 OpenForce Conference in Amsterdam I had a chance to speak to Armand Datema (@nokiko) on the same topic. The conversation occurred following my session on Advanced Skinning with DotNetNuke where I presented an early prototype of “Skinfigurator,” my module for rule-based skin loading. Armand was looking for a solution to dynamically choose a skin at run-time while overcoming the pesky ContentPane issue. If you are unfamiliar with the issue, here’s a quick synopsis…

DotNetNuke skins require the presence of a container HTML element with an ID of “ContentPane” and a runat=”Server” attribute. This is fine for most skins as it’s no big deal to define an area that serves as the default location for content (i.e. ContentPane). In the case of dynamic skin proxies (i.e. skins that load a layout based on some arbitrary set of conditions) this requirement is a problem since different layouts may want the ContentPane to be located in different places within the layout HTML.

In any event, as a result of my tinkering with skin proxies I found a clean solution for this problem. Ultimately I decided not to use it for Skinfigurator (more about the how/why in another post), however the technique is still quite useful. I promised Armand I would share it with him, and although I have been slow in making this post, it’s better late than never :-)

The solution is trivially simple and involves just one file — the skin proxy layout. Basically what this proxy does is tap into the Init event in the page life-cycle to dynamically load the skin layout control. Since this event happens prior to the point where the DotNetNuke framework skin loader does its thing, you don’t have to bother with creating ContentPane elements in the skin proxy layout. All you need is the logic for dynamically selecting which layout to display to the user. Your Here’s the code for the skin proxy layout (I called mine LayoutSelector.ascx)

&lt;%@ Control language=&quot;vb&quot; AutoEventWireup=&quot;false&quot; Explicit=&quot;True&quot; Inherits=&quot;DotNetNuke.UI.Skins.Skin&quot; %&gt;
&lt;script runat=&quot;server&quot;&gt;
	Protected Overrides Sub OnInit(ByVal e As System.EventArgs)

		Dim layout = &quot;Portal.ascx&quot;
		If (Request.Querystring(&quot;layout&quot;) &lt;&gt; &quot;&quot;) Then
			layout = Request.Querystring(&quot;layout&quot;) + &quot;.ascx&quot;
		End If
		Controls.Add(LoadControl(TemplateSourceDirectory + &quot;/layouts/&quot; + layout))
	End Sub
&lt;/script&gt;

In my example, I have the code checking for a querystring variable and loading a control based on the value provided. Of course, this is not something you will want to do in production use. More likely you will want to have conditional logic based on the user, portal, browser, tab or some other controlling factor that determines which skin layout will be loaded.

There is one other thing to be aware of that is related to usability. By default, DotNetNuke lists all layouts (i.e. user controls) it finds in a skin folder in any skin layout selector in the UI. To ensure that your proxy logic is used, you will want your proxy layout control to be the only control in the skin’s root folder. All the dynamically selectable layouts should be in a sub-folder. In my example, I use a sub-folder called “layouts.” The folder structure for your skin will look something like this:

[MyCoolSkin]
– LayoutSelector.ascx
– skin.css
– [layouts]
—– Portal.ascx
—– Portal2.ascx
—– Portal3.ascx

Using this approach, the user will only be able to choose “LayoutSelector” and the Portal, Portal2 and Portal3 layouts will be hidden from the skin layout selector UI.

WidgetsStarting with Release 5.x, the DotNetNuke platform has included a Javascript-based Widgets framework for dynamically injecting client-side interactivity into skins and modules. Like most Open Source developers, I thoroughly enjoyed coding the Widget framework but neglected to document it properly. In this four-part series I hope to correct this shortcoming. In Part 1, I will introduce some fundamental concepts of the DotNetNuke Widget Framework. In Part 2, I will provide a reference for existing widgets that are included with DotNetNuke. In Part 3, I will step through the process of developing a Widget. Finally, in Part 4 I will create a working Widget that you can download and use to increase your understanding of the framework and to build your own Widgets.

Widget Fundamentals

Just as you can add modules to a DotNetNuke page to add application functionality, so also can you add Widgets to DotNetNuke skins and modules to add interactivity. For example, in a skin, Widgets may enable a user to dynamically switch a stylesheet to change page appearance, add a photo gallery, embed a video etc. In a module, Widgets can provide interface elements for navigation, drag-and-drop sorting capabilities etc. Widgets are first-class citizens of DotNetNuke’s extensibility model and can therefore be packaged individually or in combination with DotNetNuke modules and skins using the familiar DotNetNuke manifest and zip file model. Widgets are created using Javascript code that builds on the Microsoft ASP.NET AJAX client-side library and can leverage jQuery or any other client-side framework for additional capabilities. They can be embedded into any extension type that manifests itself in the client browser (module, skin, skin object, container) and use a syntax that should be familiar to skin designers. Here’s an example of a Flickr Widget:

&lt;object codebase=&quot;EmbedWidget&quot; codetype=&quot;dotnetnuke/client&quot; id=&quot;MyWidget&quot;&gt;
    &lt;param value=&quot;Flickr&quot; name=&quot;type&quot; /&gt;
&lt;/object&gt;

That’s it…three lines of HTML markup to embed a Flickr slideshow like the image below instantly into a DotNetNuke page. Go ahead…try it out by adding the above markup in an HTML module (in source)…I’ll wait.

Flickr slideshow using EmbedWidget

At this point you are probably wondering what the benefit of Widgets is if they are coded in Javascript and make use of pre-existing client-side libraries. After all it’s not that difficult to embed a simple <script> element into your skin or module and add any code that you desire directly at the appropriate location. And using my simplistic example of a Flickr slideshow, you could just as easily get the embed code for the slideshow and use it directly.

Five Reasons for using the Widget framework

Let’s address these questions by reviewing the five primary reasons for using the Widgets framework:

Clean Markup: Using Widgets enables you to keep the HTML markup for your skin or module clean and script-free. Since Widgets are embedded using the standard <object> element, you can add functionality without sacrificing readability. In fact, Widgets lend themselves to more semantic markup as the intent of the markup is usually evident from the name of the Widget and the parameter name/value pairs. Embedding script directly or referencing an external script makes your markup harder to read and maintain.

Reusability: If you have some Javascript code that needs to be used in multiple skins or modules, wrapping it into a Widget makes it easy for you to re-use the code while taking advantage of DotNetNuke’s packaging and versioning capabilities. Sure, you could store a script file in a central location and reference it, but Widgets afford you greater control in using, deploying and maintaining the code. Furthermore, by implementing the code as a Widget, you now have the ability to easily pass parameters without messing around with querystring parameters to script file references or in-line Javascript variable declarations. Such reusability does come at a small price in terms of time and effort required, so it’s probably not a good idea to create a Widget for a single-use script.

Testability and Maintainability: Unlike context-less Javascript files or embedded script, Widgets are stand-alone, contextual entities. Therefore they can be tested and debugged in a variety of scenarios quickly and easily with minimal effort. If you just add a <script> reference to a Javascript file in your HTML markup, you have no way of knowing if the dependencies for the script are being loaded or not. You have no idea if any variable necessary to pass parameters to the script are already on the page or not. These issues are eliminated using Widgets. When you use a Widget, you know that its dependencies will be correctly loaded and its parameters are available in the Widget’s HTML markup itself.

Performance: Browsers execute inline script and fetch scripts referenced using the <script> element synchronously while rendering a page (you could use the “defer” attribute, but browser support for this is not consistent). This puts an unnecessary wait penalty on the site visitor. Using jQuery’s document.ready() method mitigates this somewhat, but remember, the browser still has to switch context from HTML to Javascript, parse the script and then switch context back to HTML. Widgets provide a cleaner way to add client-side interactivity as they are loaded at the end of a page when the DOM is ready. Thus, the visitor will have a better user experience as HTML, CSS and images will already have been rendered. If you would like to learn more about how browsers handle script, read Timing and Synchronization in JavaScript.

Behavior Injection and Modification: It’s quite easy to add “onclick” and “onmouseover” attributes to HTML elements to add client-side interactivity. Unfortunately, this results in horrible markup that is difficult to maintain and difficult to debug. Widgets force you to use behavior injection and modification in order to attach events to DOM elements. This keeps all behavioral code in one location and makes it incredibly easy to maintain through good use of jQuery selectors. It’s also results in a cleaner separation between the markup and the script.

Hopefully this information has provided you with enough knowledge to understand when Widgets are a good idea and when they are not. Now let’s take a deeper look at the client-side page life-cycle to understand the Widget rendering process.

Widget Rendering Process

Widgets are rendered only if the Site Setting “Enable Skin Widgets” is checked. This value is checked by default, so you can be assured that Widgets will render on most DotNetNuke sites. (We should probably re-name this setting to “Enable Client-side Widgets”…when I was first coding the Widget framework, I was focused on usage scenarios involving skins and used the term “skin widgets.” The term stuck even though Widgets can be used in any DotNetNuke extension that renders code to the browser.) By enabling this setting, a single reference to a Javascript file is injected into the very end of the page:

&lt;script type=&quot;text/javascript&quot; src=&quot;/Resources/Shared/scripts/initWidgets.js&quot;&gt;&lt;/script&gt;

When the script loads, it initiates a four-step process: Framework Initialization, Widget Detection, Widget Instantiation and Widget Rendering. This process is illustrated below:

Widget Rendering Process

The Widget framework uses jQuery to load all required scripts in an asynchronous manner. When a script is done loading, an event is fired to carry out the next step in the rendering process. All of this happens pretty fast, and most notably, after the page is already rendered in the browser. If you view the HTML source for the page, you will see no difference in the markup from what was originally sent by the server (i.e. <object> elements). However, if you query the DOM using FireBug or a similar tool, you will see that each <object> Widget element has been replaced with a <div> or similar element with the same ID as originally given to the <object> element. This enables you to use CSS for styling the Widget using an ID selector (i.e. #MyWidget).

In this post, I provided an introduction to the DotNetNuke Widget Framework. In the next post in this series, I will introduce you to the Widgets included with DotNetNuke and provide a usage reference for each Widget.

A visual overview of DotNetNuke intended to give newcomers to the platform a quick understanding of DotNetNuke.

DotNetNuke Architecture

(Click for larger image)

© 2012 TechBubble Suffusion theme by Sayontan Sinha