Archives
-
Get Module by Module ID in DotNetNuke
When building [DotNetNuke] modules, a number of times I've run up against the issue of trying to instantiate a ModuleInfo instance with only a module ID. However, the GetModule signature on ModuleController takes both a module ID and a tab ID. In this latest instance where I've come against this issue, I was actually trying to get a tab ID based on the module ID, so I obviously didn't already have one to provide.
As I started to move down the road of writing my own query to get this simple thing done, I found that the GetModule method and underlying query will take a "null" value for the tab ID! Unbeknownst to me, the solution was right in front of me, right where I expected it to be the whole time, I just couldn't see it.
So, if you need a ModuleInfo instance and you only have a module ID, call GetModule(moduleId, Null.NullInteger) and you're good to go!
(I've put in a request with the people in charge to add an overload to GetModule so that this is more obvious going forward)
-
Check your CSS for DotNetNuke 4.9.0
I started on an update to one of our modules for [DotNetNuke] this week, and was surprised to see many of the administrative pages looked like they had no styles applied to them. Tables were jumbled, with no differentiation between header and or row content; things just didn’t look right.
As I tried to adjust some of those styles, I came to realize that the issue was, in fact, a change in the behavior of [DNN]. While before, when I accessed a control in the admin directory of my module, the module.css file in that directory was referenced; now the module.css in the main folder of my module was referenced (that is, previously DesktopModules/MyModule/admin/module.css was referenced, but now /DesktopModules/MyModule/module.css is referenced).
After some digging, I figured out that the change happened in [DNN] 4.9.0 (the latest version) and found mention of it in [DotNetNuke]'s Issue Tracker. So, now, the moral of this story. Starting in [DotNetNuke] version 4.9.0, only the module.css in the main folder of a module is referenced, regardless of where the control being loaded lives (unless there isn't a module.css there). Therefore, you only need one module.css to control the styles of all of your controls. This is great news from a maintainability standpoint.
However, if your modules still need to support versions before 4.9.0, we need to figure out how to manage this relationship. It seems obvious that, to support 4.9.0, we need to combine all of our stylesheets from whatever folders they may be in currently, creating one stylesheet for all our controls in our module’s root folder (I used CleanCss to combine them and remove duplicate styles).
Now, after the obvious choice, we have to face the less-obvious choice of how to provide those same styles on pre-4.9.0 sites. My first instinct was to remove all content from the module.css in my admin folder, and replace it with an import to the main module.css, that is
@import url('../module.css'). This may work, but I wasn’t sure if the browser would cache that reference, and it seemed wrong to have to load two files just to get to the real one. What I ended up deciding was to create a Post-Build Event in my project to copy module.css from my module’s root folder into the admin folder (which looks likecopy $(ProjectDir)module.css $(ProjectDir)admin/module.css).Hopefully this provides you module developers with a good guideline for what’s going on and how to deal with it when you come across your modules acting like they’ve never heard of this “stylesheet” you keep telling them about.
-
Tulsa TechFest 2008 Wrap-Up
We at Engage spent the end of last week in Tulsa, presenting and participating in the 3rd annual Tulsa TechFest. My colleague Ian has written up a great review, with links to all of our presentations on his blog.
I presented on Building a DotNetNuke Module, walking through the Visual Studio project template that we just released, demonstrating what DNN requires of and offers to developers of modules.
We had a great time and really enjoyed the turnout for our sessions. We hope that those of you who attended were able to learn from us, and we were glad to get some time to learn from the community as well. Hope to see you guys again next year!
-
C# Compiled DotNetNuke Module Template
It shouldn't be hard to get started writing a module for [DotNetNuke], but it doesn't seem like there's a whole lot of help especially when you are wanting to use C#. At Engage, we have created a Visual Studio project template which will get you started developing a C# [DotNetNuke] module, using a Web Application project (rather than the, in my opinion, much more cumbersome Web Site project). It is available for free on our downloads page after registering on the site.
The template will get you started with the basics of a [DotNetNuke] module, providing basic placeholder controls (for view, edit, and settings), base classes to use for your module controls and your settings control, a manifest and NAnt build file to easily package your module, and the basic starting point (and sample code) for your business controller class and data provider. It should really speed up how you start a new module, and free you from always copying your last module and then having to figure out what to delete and what to leave.
To use the template, put the downloaded zip file into the C# web templates folder for Visual Studio. This is typically in My Documents/Visual Studio [2005|2008]/Templates/ProjectTemplates/Visual C#/Web (you might have to create the Web folder yourself). This will make the new project type appear under the Web node for C#, in the My Templates section, when you create a new project. You might also want to open up the zip file and alter the template manifest (C# Compiled Module.vstemplate) to include your company name (replace the values in the CustomParameters section where it says YourCompany).
Please check it out, we hope it helps you out. Happy module building!
[Cross-posted from http://www.engagesoftware.com/Blog/EntryID/162.aspx]
-
Introducing Engage: Events 1.0
After three public pre-releases, and weeks of wrestling through user-submitted bugs and those we found (so that you don't have to!), we are now ready to release Engage: Events to the eagerly awaiting public! After we cemented our feature-set in the Beta release, we have hunted down no less than 15 bugs, ranging from grammar to complete show-stoppers. We are very thankful for the support of the community as we worked together to create a [DotNetNuke] module that fits your needs, from the ground up, based on your suggestions.
And, to be clear, this is only the beginning. This is the first "production-ready" release of this module, but it is definitely not the last. We have already heard a good amount of suggestions from our Beta period that we couldn't incorporate into the product for 1.0, but we will definitely be looking into those again (and any new suggestions) as we move forward to continue adding improvements and functionality to Engage: Events, without compromising quality or aesthetic.
If you haven't already taken a glance at the module during the pre-release phase, or you want to see the new rock solid 1.0 before you upgrade from the Beta, take a look at our demo site, where you can log in as a user or an administrator and play around with all of the options available in the module. We're excited for you to try it out and let us know what you think.
[Cross-Posted from: http://www.engagesoftware.com/Blog/EntryID/160.aspx]
-
DotNetNuke Gotcha: Upgrading DotNetNuke Modules
I was recently tasked with investigating a mysterious error on a customer's site, which I finally tracked down to an oversight in the upgrade process of a [DotNetNuke] module. The error threw up a YSOD, (though in later testing on a different site, it also showed up in a regular [DNN] red triangle error message), with an error message like "Multiple controls with the same ID 'ctr376' were found. FindControl requires that controls have unique IDs." Talking it through with Chris, we figured out that there were two entries in this module definition for the same control key. So, when we tried to go to the Edit control, [DNN] was attempting to load two different .ascx controls in the Admin control, which caused the whole thing to kind of blow up and die.
So, how did we get two controls registered for the same control key? The answer was obvious enough, probably because it's bit me before: upgrades. When you upgrade a module in [DNN], the installer adds any new control definitions that it finds in your module's manifest file. It doesn't, however, remove control definitions that it doesn't find any more. This means that if you rename a ControlKey, or, as in this case, you rename a control itself, you'll have duplicate entries pointing to incorrect information. Most of the time this isn't too much of an issue, but sometimes it'll cause mysterious errors that take up your morning before you figure them out.
The solution: Be aware when you are renaming or removing any entries from your module's manifest. When you find yourself renaming, make sure that you add a line to that version's SQL script to remove the old entry from the database. At the very least this keeps your module definition clean, and it also avoids nasty, hard-to-track-down bugs. This would look something like
DELETE databaseOwner.[objectQualifier_ModuleControls]WHERE ControlKey = 'Edit'
AND ControlSrc = 'DesktopModules/EngageSample/Edit.ascx'
One other note, if you rename or remove a control from your module, there's also a mechanism to have those removed from the site upon upgrade. If you add a text file with the name of the version to your module (and to your manifest's files section), [DNN] will look for any files listed in that file, and delete them if it finds them. For example, if I rename Edit.ascx to EditSample.ascx in version 02.02.05 of a module, I can add 02.02.05.txt to the module package and manifest. This file would contain one line, "DesktopModules/EngageSample/Edit.ascx" and I could add additional lines for other files, including files in the bin folder, if I needed to. Upon uploading the new 02.02.05 module package, no more Edit.ascx.
These two techniques, applied together, can help keep your module nice and tidy as you upgrade, and keep all of those mysterious, day-stealing errors away.
Hope it helps!
[Cross posted from http://www.engagesoftware.com/Blog/EntryID/161.aspx]