There are all kinds of ways to make a skin (or design) in DotNetNuke react in a dynamic or personalized fashion, and it can be done in any number of ways. To date, my favorite article on how to do this was written by Vassilis Terzopoulos (@thinkofdesign). As his Hook Your DotNetNuke Skins blog post illustrates, a "user control" style skin allows you to use and reuse the DotNetNuke API in your skin design. This has potentially limitless potential in customizing the user experience from a very high level across your entire site.
Personalization
One of the many ways to provide a dynamic experience for your website visitors is to “personalize” their experience. There are many examples of personalization out there, from the iGoogle approach, to targeting content based off of user activity. No form of personalization is wrong, as long as it adds positive value to the experience that your website visitors have while visiting your site.
I am going to focus on something very specific in terms of personalization for this blog post. I am going to talk about serving up a specific design to your visitors, based upon the security role (or group) that your visitor belongs to.
Did you know that DotNetNuke has a personalization engine in the API? It is pretty impressive. You should take a look and build something cool with it. ;)
Background: Loading Skins
There are a few different ways to dynamically or programmatically change the skin for a specific page load. DotNetNuke will look first for an override value in the URL. If specific value is found, then DNN will load that skin and/or container on that page load. Second, DNN will look in a local cookie to see if there is a skin being defined. Finally, if the first two methods did not specify a skin to load, DNN will load the default skins defined by the page or site. In the event that the skin doesn’t exist, the default skin that ships with DNN will be loaded.
This is why it’s important to not delete the original skin package after installing.
Probably the best way to approach dynamically loading a skin based on security role would be to create a simple cookie using either a DotNetNuke module, or HttpModule. Either way, you will be able to retrieve the user information, and based on the IsInSecurityRole() property, generate a cookie that will in effect load the desired skin.
The Code
This solution is dependent upon the skins in question already being installed, and knowing which security roles there are to use for this purpose. I am simply going to provide you the starting point in this blog post by means of a code snippet. It will be up to you to find a cool way to use this in your own solutions.
Basically, this solution requires that you have access to the current HttpContext object. This object must have the context of the current web request, or be spoofing it.
The snippet of code below assumes that you want to assign the built-in DarkKnight homepage skin to an imaginary security role you've created called "My Security Role." Also note that you can use the UserController.GetCurrentUserInfo() method to get the current user object – provided that your code has the current HttpContext.
VB:
' import DotNetNuke.Entities.Users
If Not Me.UserInfo Is Nothing AndAlso Me.UserInfo.UserID > Null.NullInteger Then
If Me.UserInfo.IsInRole("My Security Role") Then
' import System.Web.HttpCookie
Response.Cookies.Add(New HttpCookie("SkinSrc", "GSkins/DarkKnight/Home-Mega-Menu.ascx"))
Else
' either assign another skin, or do nothing
End If
Else
' either assign another skin, or do nothing
End If
C#:
// using DotNetNuke.Entities.Users
UserInfo oUser = UserController.GetCurrentUserInfo();
if (this.UserInfo != null && this.UserInfo.UserID > Null.NullInteger)
{
if (this.UserInfo.IsInRole("My Security Role"))
{
// import/using System.Web.HttpCookie
Response.Cookies.Add(new HttpCookie("SkinSrc", "GSkins/DarkKnight/Home-Mega-Menu.ascx"));
}
else
{
// either assign another skin, or do nothing
}
}
else
{
// either assign another skin, or do nothing
}
Keep in mind that the above are just your starting points. You can set this up and write the production code any way that you’d like. The string value of security role would be pulled from a setting of some kind in the UI, where you would have queried the security roles that are in production. You would need defensive code that checks to make sure that the security role still exists (people can and will delete it).
However, the point should be pretty clear to you. You can define a user specific cookie that loads a skin that is specific to the user. If you want, you can base this off of user profile properties and pretty much anything else your code has access to.
The G value references the path to skins that are installed in the Host directory. Skins that are installed for a specific portal would use L instead.
If you want to do the same thing for a container, use a cookie named ContainerSrc instead of SkinSrc.
Now you have all of the information you need to be able to pull off some magic with the design and personalization on your DotNetNuke website. The rest is up to you.
With DNN… You’re only limited by your creativity.
This blog post is cross-posted from my personal blog site.