Archives
-
Engage: Employment 1.4 for DotNetNuke
Have you heard of our Engage: Employment module for [DotNetNuke]? I'm talking about our module for posting job listings on your website and allowing folks to apply for them. We have today released a new version of the module to fix a number of bugs that have been discovered, while completely revamping the administrative experience.
Where before it took about a million clicks to get the module setup and to get a good understanding of how it was setup and what had already been setup, now you're initially greeted with an administrative overview, with quick, one-click access to every part of the administrative interface. We think this will save you hours if you're setting up a site of any significant number of job listings.
We've also added the much requested ability to send notification emails to different people for each job, to allow for easier management and delegation of responsibilities when dealing with new applicants. These new applications can also be given statuses to track the movement of the application through your hiring workflow (before you were stuck giving statuses to the users themselves, even if they were great for one position but terrible for another).
Finally, we improved the searching experience, adding the ability to search by job categories and to use quoted phrases when doing a keyword search.
And this is all in addition to the bugs we found and fixed from the previous version. We really think this is the slickest, most intuitive, and most stable release of the module yet, and we have some great ideas for where to take it next to increase its appeal even more. You can see what we've done, where we're headed, and submit your own bugs or suggestions at our issue tracking site.
If you haven't used the module before, or you want to see the new features in action, you should take it for a spin on our demo site. Here you can login as an administrator and a user, and see what the experience is like from start to finish.
-
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]
-
Engage: Events Alpha.2 is released!
We, at Engage: Software, have released an update to the Alpha release of our new Events module for [DotNetNuke]. This update adds some fixes for bugs that we found after the first Alpha release. It also includes templating, so that you can have complete control over how your website looks.
Please register on EngageModules.com, and try out this free download from the Engage: Events page. You can ask questions on our forums, and let us know about any bugs you find or features you'd like to see on our issue tracking site. We really want to hear what you think so that we can make this a module that truly fills all of the needs of our users.
[Cross-Posted from: http://www.engagesoftware.com/Blog/EntryID/153.aspx]
-
Announcing the Alpha release of Engage: Events!
After weeks in the top secret laboratories at Engage Software, we are now ready to bring our newest creation into the light. We would like to announce the immediate availability of Engage: EventsAlpha!
Taking a look at the [DotNetNuke] landscape, we realized that the world of event management needed a new leader, a new vision. We have begun to create that vision in Engage: Events. We are committed to a clean, elegant design to make sure that it integrates cleanly with your site, whatever design it may have. The Alpha release of Engage: Events comes with an event listing and calendar view. Registered users can register for events and administrators can view their responses. It also includes iCal support.
This is an alpha release, which means that it is not feature-complete, and it may have problems. Please be aware that this should not be used on a production site, and we provide no warranty if something goes wrong. That said, we've been playing with it and have seen only minor, cosmetic bugs. We wanted to get this release out to you, the public, early, so that you can take a test drive, kick the tires, and let us know what you think needs to be changed, kept the same, added or removed. We want to know what you want from an events module.
To try it out, check out the Engage: Events page on our site, and click the free download link. Note that this is a limited time demo version, and will expire in a couple of months. This is accomplished through the use of a licensing web service, please see our documentation for more information.
The whole reason this module is being made available to you is so that you can help us meet your needs. Please join the discussion for the future of event management on our forums, and tell us about any bugs you see or ideas you have at our new bug tracking site.
[Cross-Posted from: http://www.engagesoftware.com/Blog/EntryID/152.aspx]
-
A DotNetNuke CSS Selector Skin Object
On our DotNetNuke module demo site, we have a little selector (pictured above) in the upper right hand corner that lets you pick how wide you would like the site to appear. This is based on a similar mechanism on the DNN site. Folks have been asking about it, so feel free to register on our site and grab it for yourself (for free). It is a DNN skin object and compatible with DNN 4.5.1 and up. This is something we've developed for internal use, so it may or may not work for every circumstance. The basics are that it allows your users to define how they want to site to look by defining a CSS file with a cookie value.
The package you get has a .dll (to put in your website's bin folder) and an .ascx control to use on your DNN site as a skin object. Once you have everything in the right place, you can start using the skin object in your skin. It's still a pretty manual process, though it shouldn't take too much work to register is as a skin object on your site and use it that way. For our site, we do something that looks a little like this:
<%@ Register TagPrefix="engage" TagName="CssSelector" src="/Portals/_default/Skins/DNN-Blue/CssSelector.ascx" %><engage:CssSelector runat="server" ImageFileName="images/narrow.gif" SelectedImageFileName="images/narrow_sel.gif"
AlternateText="Narrow" PropertyName="Width" Value="Narrow" />
<engage:CssSelector runat="server" ImageFileName="images/wide.gif" SelectedImageFileName="images/wide_sel.gif"
CssFileName="wide.css" AlternateText="Wide" PropertyName="Width" Value="Wide" />
<engage:CssSelector runat="server" ImageFileName="images/full-width.gif" SelectedImageFileName="images/full-width_sel.gif"
CssFileName="full-width.css" AlternateText="Full-Width" PropertyName="Width" Value="Full-Width" />
We first register the skin object (that first, yellow line). Then we put the selector on the page for each option we want to present. Each instance sets a number of properties to get it setup. Firstly, there's the SelectedImageFileName and ImageFileName, which is a local, relative path to the image to display when that option is selected or not. Next is the AlternateText, set to the alternate text of the image. You'll notice that only two of the three options here specify the CssFileName property. The instance without a CssFileName specified is considered the "default" value, and appears selected if the user hasn't selected any of the options. Once the user selects an option, the page reloads, and the specified CSS file (typically containing an override of one or two styles) is also loaded. The user's selection is stored in a cookie, which is where the PropertyName and Value properties come into play. The PropertyName is the name of the cookie, and the Value is the cookie's value. This allows you to setup multiple different sets of buttons (like at DotNetNuke) for different types of properties.
Please visit our support forums if you have any issues, or if you want to let us know what you think.
[Cross-posted from http://www.engagesoftware.com/Blog/EntryID/145.aspx] -
Hierarchical checkbox selection with an Infragistics UltraWebGrid
I was tasked yesterday with adjusting a hierarchical Infragistics WebGrid (2007.2, but I don’t expect that it’s substantially different in any other recent versions) so that when a checkbox was checked in a parent row that the children rows’ checkboxes were also checked. This proved much more difficult than I expected, in part because I overlooked the client-side event that I needed to use. After struggling with trying to figure out what server side or client side event would fire after a checkbox was checked, I finally found the AfterCellUpdate client side event. There were a few other gotchas that cropped up along the way too, so I thought I’d share my final product for anyone else who might want this same behavior.
To wire up the event, you need to set the DisplayLayout.ClientSideEvents.AfterCellUpdateHandler property to the name of the JavaScript function that should handle that event (ugUnitTypes_AfterCellUpdate in my case). If this isn’t exactly what you need, the WebGrid CSOM topic in Infragistics’ help documentation was indispensible for traversing their particular brand of JavaScript jungle.
I hope this helps you.
function ugUnitTypes_AfterCellUpdate(gridName, cellId) {
var cell = igtbl_getCellById(cellId);
if (cell && cell.Band.Index === 0 && cell.Column.ColumnType === 3) {
var parentValue = cell.getValue();
var children = cell.Row.getChildRows();
for (i = 0; i < children.length; i++) {
var childCell = igtbl_getRowById(children[i].id).getCellFromKey( 'Selected' );
childCell.setValue(parentValue);
}
}
}[Cross-posted from http://www.engagesoftware.com/Blog/EntryID/141.aspx]
-
Introducing Engage: Rotator 1.2 for DotNetNuke
Today marks the release of the next version of our content rotation module for [DotNetNuke], Engage: Rotator. One of the biggest difficulties customers have been having with the module is trying to get it to look like the examples we show, and specifically how it looks on our website. With version 1.2, we have eliminated some of the big hurdles in the way of creating great looking rotating content. We have added some pre-defined styles to the module that will get you up and running in no time flat. We hope this really helps everyone get to their goal of a great looking website with great looking content. Check it out!
[Cross-posted from http://www.engagesoftware.com/Blog/137/EntryID.aspx]
-
Announcing Engage: Employment 1.3
We at Engage Software have just released the latest update to our [DotNetNuke] Jobs Listing module, Engage: Employment, version 1.3. This is a module you can use on your company's [DNN] site to list the job openings you have available at your various locations, and accept and sort applications and applicants.
In this version we have made significant enhancements to searching both within the module and through [DNN]. Searches return more relevant results and are now marked to show why they are relevant. The module is also indexed by [DNN]'s search indexer now, which incidentally also allows for the module to be syndicated through an RSS feed.
We also added the ability for applicants to return and update their application, including their resumé and cover letter, as well as their salary requirement and application message.
Lastly we began the update to the administrative side of the module, rearranging the applications to be grouped by job opening.
Feel free to check out this and all of our other modules at our demo site, http://demo.engagemodules.com, where you can feel free to try out all that the module has to offer and see if it will meet your needs. We're very excited to be able to support the requests of our community with this new release and with our future plans for the module.
-
DotNetNuke Site Compile Error: "BC30451: Name 'Initialize' is not declared."
Today was at least the second time that I had seen the above error happen on my local development [DNN] site. I don't know what happened, maybe I accidentally recompiled the source with something strange in there (though the date on the assembly didn't seem to indicate that), but replacing DotNetNuke.dll in my bin folder with a fresh copy made it go away. Hopefully this'll help someone else out in the same situation.*UPDATE*: I later realized that I had compiled a project with references to an earlier version DotNetNuke, and those references were set to Copy Local. Moral of the story: make sure you're running what you think you're running.
-
Navigating with Environmental Variables
As a developer, and specifically as a [DotNetNuke] developer, there are a number of directories that I have to navigate to regularly. In particular with DotNetNuke, I'm going to C:\inetpub\wwwroot\DotNetNuke\Website\DesktopModules quite a bit. So, instead of having to try to type that in all the time, or navigate through the folder structure, I've defined an environment variable "dm" that is defined as that path to my Desktop Modules folder. I can just type %dm% into an explorer prompt and be there without any hassle. I've also setup a %wwwroot% shortcut, though it gets used much less often. It's a lot like keeping a shortcut around in your dock/quick launch toolbar, but you can also use it in dialogs. Hopefully this can help you trim off a few more seconds/minutes of monotony throughout your day.
What other solutions do y'all have for getting around to your often used files/folders?
-
Technorati Claim
-
Howdy, All
Hey, there, welcome to my blog. I'm going to be writing about the everyday encounters I have with writing code, mostly for DotNetNuke, and what I discover while doing that. I hope it can help you out. I'll get a real informational post out here before too long, though if you want to see some of what I've written before from my other blog, check out http://www.engagesoftware.com/Blog/tabid/297/BlogID/11/Default.aspx.
That's all for now!