Contents tagged with DotNetNuke
-
DNN World 2012
I just returned from DotNetNuke 2012 and wrote up a review of the experience at my Engage Software blog.
-
DNN World 2011
We’re on the plane flying back to St. Louis from DNN World 2011. I gave a presentation titled DNN 6 UI/UX Patterns, discussing the form patterns introduced in the administrative modules in DNN 6 (the new look and feel that you immediately noticed after logging into your new DNN 6 site). Many folks asked about seeing the examples that I presented, and they are available as a repository on github, at https://github.com/bdukes/DNN-World-Demos. This includes a series of small, one-control modules that demonstrate the various parts and pieces introduced in DNN 6. I’ve also placed the slide deck on SlideShare, (though the vast majority of the content was just demonstration, don’t be expecting a wealth of information there). Feel free to let me know if you have any questions, and I’ll do my best to give clarifications.
-
Why isn’t My Scheduled Task Executing?
A quick diversion from the JavaScript Common Difficulties and Misconceptions series (I have another post queued up, just need to write the sample code), for an issue I just ran into.
Created a scheduled task for DNN, but it’s sitting in the scheduler queue, just getting more and more overdue. Why won’t my task run?
Somehow I missed the constructor from the tasks I copied. Your task needs a constructor that takes a
ScheduleHistoryItemto run via the scheduler. -
Chicago Day Of DotNetNuke 2010 Recap
Saturday, October 2nd was the Day of DotNetNuke in Chicago. A number of us from Engage attended and spoke. I gave two presentations, which are now available on SlideShare (linked below). I’ve added some notes (be sure to click the “Notes on slide 1” tab when viewing on SlideShare) to give context if you weren’t able to attend the session.
Considerations with Writing JavaScript in your DotNetNuke® site Overall, we definitely were glad to participate in the event. The logistics were pulled off excellently (you certainly couldn’t tell that none of the organizers had organized an event of this magnitude before). I was also great to see the number of community leaders that were presenting and available. It really was a treasure-trove of DNN knowledge.
Nik Kalyani, the keynote speaker, did a great job of emphasizing the role that the community needs to play in guiding the development of DNN. A lot of us walked away excited about what we could contribute to move the community and platform forward.
Nik introduced the concept of a DNN Meme. This is an idea about DNN that catches on with the community in a way that it cannot be ignored. The basic idea is that if an idea is too good to resist, we need to share it so that something actually happens with it. Nik suggested that we use the hashtag #dnnmeme on twitter, and post bigger ideas to dnnmeme.com (via emailing post@dnnmeme.posterous.com). I’m not sure that the “DNN Meme” name is going to take off, but I can definitely get behind getting our ideas out there, gauging community interest, and pursuing the things that we all know that DNN needs.
In Nik’s session at the end of the day, we discussed a couple of things (documented on dnnmeme.com). The biggest of which was the need for module developers to get together and see where we can come to some agreements on how to implement our modules (whether that be a more standard set of markup/CSS, new features in the DNN core, or an agreement on how to implement large amounts of settings). Based on that discussion, Will Morgenweck created the DotNetNuke Module Standards project on CodePlex, where we can start the discussion of standardizing our approaches to modules.
If you are a module developer, we’d love your input on the patterns that you use when developing modules. Specifically, where you find yourself working around what the core provides, or find that the core doesn’t provide anything to support what you’re doing. We’ve gotten the discussion started with what we do and would like to do, but we need more voices so that we can come up with some real consensus on how to reconcile our different approaches.
-
My Messages Inbox: A Mobile DotNetNuke Application for the St. Louis DNN Hackathon
This past week was the St. Louis DotNetNuke Hackathon. This was a competition for DNN developers to create a mobile application which interacts with DNN. We had one week to create something worth showing off. So, I, along with another developer at Engage, Abadi, took the challenge.
Abadi has experience developing games for Android phones, so we decided to write a Java application (rather than using Appcelerator’s Titanium Mobile product) which could connect with the Messaging feature introduced in DotNetNuke 5.3. If you have a DNN 5.3+ site, you’ll see a module titled “My Messages” on your profile page, which you can use to send messages to other users on the site.
As we were brainstorming what would make a good DNN mobile application, Rich Campbell, Engage’s president/CEO, tossed out the scenario of being notified of a football game being rained out. We all decided that going mobile would add a lot of value to DNN Messaging, and My Messages Inbox was born.
Before I go into the technical details, let me first point out that the Hackathon is currently in the voting phase (until tomorrow, August 31st, at 6:00 Central), so head on over to view the entries, and vote for your favorite!
So, technically, the application comes in two parts. I worked on an extension to your DNN site that enables communication with the Android application that Abadi wrote. The extension contains a WCF web service which allows a user of the site to authenticate and then get a listing of their messages. I’m very happy with how cleanly I was able to interface with the Messaging code (thanks, in large part, to the separation enforced by use of the Web Forms MVP pattern in the Messaging module). This was also my first big leap into using WCF, so it was great to be able to figure out how to integrate it with DNN without needing tons of configuration and setup (with much thanks to Justin Etheredge’s timely blog post on the subject, as well as Steve Fabian’s WCF DNN Security post).
Abadi was a wizard at figuring out the best way to integrate with the Android interface. He’d never worked with web services in Android before, so we had to catch up on how to get connected, how to parse JSON (and, especially, dates in JSON), and how to layout a standard interface. The most awesome feature of the entry, I think, is the ability for our application to check for new messages in the background, while you’re using other applications on your phone, and receive a notification (just like email). Since we were using Android itself, and not the common iPhone/Android abstraction that Titanium provides, we were able to take full advantage of the multi-tasking built into Android to make that happen.
Overall, it was a lot of fun, and a great learning experience all around. Many thanks for Pat Renner for his management, guidance, ideas, and filming (that’s his voice in the YouTube video), and for Anthony Overkamp for the great images we used on the Hackathon Entries page and the Codeplex site. Remember to go to the Hackathon page and vote!
-
DotNetNuke & MVC
Earlier this week, Shaun Walker, [DotNetNuke]'s Co-Founder and Chief Architect, caused a bit of a ruckus in the blogosphere/twitterverse with his blog post ASP.NET MVC and DotNetNuke. I think many disagreed with his representation of ASP.NET MVC, whether or not they agreed with the actual point of the blog post (to announce that [DNN] is not going to be ported to ASP.NET MVC). Unfortunately, much of the discussion became a little too heated, so I think we are all glad to be able to move on to more productive discussions now that the backlash has died down some. Charles Nurse has led the way forward for productive discussions by blogging about his recent work integrating an ASP.NET MVC application into a [DNN] site as a real [DNN] module. It's very exciting stuff, even with the list of known issues. Hopefully we can move forward on this front and allow both WebForms and MVC-style development within the [DNN] ecosystem, making it richer for its diversity.
Also, if you are interested in learning about MVC, TekPub's Rob Conery has donated coupons for their ASP.NET MVC series to [DNN]. All you need to do to get some free (excellent) training on ASP.NET MVC is to blog about [DNN] and leave a comment about it.
-
ASP.NET Markup Guide
One of the biggest gaps between developers and designers at our company is the disconnect between ASP.NET web controls and HTML markup.
Our designers are very comfortable working in HTML, and passionate about using semantic markup to communicate the structure and meaning of web sites. Our developers, on the other hand, understand the functionality of most of the web controls that ASP.NET provides, but are usually more concerned with the functionality that they provide, rather than the markup that the produce.
To help begin bridging this gap, I created an interactive guide to the markup produced by the various standard ASP.NET web controls. You can take a look and contribute at the repository on GitHub.
Right now, when you pull the files down from the repository, you'll have a control with the actual guide on it, another control which you can register with [DotNetNuke] to make it into a [DNN] module, and a plain ASP page, Default.aspx, which you can use to view the guide outside of [DNN] (Phil Haack's Web Server Here shell extension might be useful for viewing that page without having to setup any real website).
The guide consists of three columns in a table. The left column contains some ASP.NET markup. The right column contains the rendering of that markup. The middle column contains a list of the HTML elements and their attributes which the control renders. The contents of the middle column are dynamically generated when the page loads, using jQuery. This means that the results are always accurate for your current situation (whether you're using a downlevel browser, ASP.NET 4.0's new cleaner markup, the CSS Friendly Control Adapters, or just want to see how the control tree on your site affects the rendered Client IDs). Also, when you hover your mouse over that middle column, the entirety of the HTML is displayed in a tooltip.
At this point, I think the guide is useful and helpful, but there are definitely improvements to be made. Firstly, some styling, so that it's not painful to the eyes to find this information. Secondly, some of the more complicated controls could probably use some more examples, and the controls that aren't in the "Standard" toolbox also need to be represented (e.g. GridView, ListView, etc). Also, some sort of navigation or searching, especially with the addition of more examples.
If you find this useful, leave a comment, and consider forking the repository on GitHub and implementing an extra example, or a new feature.
Hopefully this can help us all get on the same page, and know when an <asp:Label/> is a <label> and when it's a <span>.
-
Engage: Rotator 2.0
-
Compile Error Message HTML
Server Error in '/dotnetnuke_2' Application.
Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: BC30451: Name 'Initialize' is not declared.
Source Error:
Line 81:
Line 82: ' stop scheduled jobs
Line 83: Initialize.Init(app)
Line 84:
Line 85: ' log APPLICATION_END event
Source File: C:\Inetpub\wwwroot\DotNetNuke\Website\App_Code\Global.asax.vb Line: 89
Show Detailed Compiler Output:Show Complete Compilation Source:
Version Information: Microsoft .NET Framework Version:2.0.50727.1433; ASP.NET Version:2.0.50727.1433
-
Packaging Modules for DotNetNuke 5
So, the first thing I noticed when testing Events in [DNN] 5 was that it seemed like some of our shared base assemblies weren't being updated to the latest version that comes with Events. Looking into it further, I realized that those assemblies were associated with the other Engage module I had installed on the site, Engage: Locator. The short story is that [DNN] now keeps track of assemblies when you install them, to help keep assemblies from being uninstalled or overwritten incorrectly. When you install a [DNN] 4 module, it appears that it sets the version of the assemblies that it installs to the version of the module. So, I had installed Locator 1.4, which gave Engage.Dnn.Framework.dll a version of 1.4.0 in the [DNN] database. When I installed Events 1.1, [DNN] thought it was an older version of Engage.Dnn.Framework.dll (1.1.0), even though it was actually the most recent version.
So, to help fix this as much as we could, I decided it was time to figure out this 5.0 packaging stuff and create a 5.0 package for Engage: Events. First, I asked [DNN] to make a module package of Events, based on the [DNN] 4 package I had installed. I looked through that and updated and removed parts to get it closer to what we wanted. Specifically, I removed the <eventMessage> section from the Module component, since... I couldn't figure out any reason we'd need that. I think it might be necessary now if you implement IUpgradeable, but it's best to try it out for yourself.
I also removed all of the files other than scripts, cleanup, and assemblies, since we use a Resource File .zip to avoid having to change the manifest whenever the content files in the module change. In [DNN] 4 manifests, this looked like a <resourceFile> element in the <folder> element for your module, pointing to the file to unzip with all of your files. In [DNN] 5, that didn't work. After a bit of searching, I found Erik's blog post, DotNetNuke 5 Extention Packaging. This helped my a ways along my path, showing that these Resource File .zips have their own section in the manifest file. After a bit of trying to figure out why his example wasn't working for me, I figured out that he'd left out one of the elements (the interior <resourceFile>) in the XML. With that figured out, my section looks like this:
<component type="ResourceFile">
<resourceFiles>
<basePath>DesktopModules/EngageEvents</basePath>
<resourceFile>
<name>Resources.zip</name>
</resourceFile>
</resourceFiles>
</component>
Back to the first issue I had experienced, I could now specify my own versions for the assemblies that I included in the package. This isn't necessarily a magic bullet, though, until all of our modules have a [DNN] 5 package. This is because the correct version of some of the shared assemblies (e.g. Engage.Dnn.Framework.dll) is still lower than the version of some of our [DNN] 4 modules. (For example, the version of Engage.Dnn.Framework.dll released with Events is 1.1.0, but the latest version of Locator is 1.4.0). So, if those are installed, we'll see the same inability to overwrite the shared assemblies with newer versions. But, this is the first step towards getting there. Accurate information is better than inaccurate, in my book.
The next change to be made to the generated manifest is to fill in the <owner> section at the top of the package. We can supply a <name>, <organization>,<url>, and <email> that is shown when the module is installed. This makes sure people know who wrote the module and how to find us. From Erik's post, I also found out that you can include HTML in those fields, so you can make the <url> and <email> links, rather than plain text. Our section looks like this:
<owner>
<name>Engage Software</name>
<organization>Engage Software</organization>
<url><![CDATA[<a href="http://www.engagesoftware.com/">http://www.engagesoftware.com/</a>]]></url>
<email><![CDATA[<a href="mailto:support@engagemodules.com">support@engagemodules.com</a>]]></email>
</owner>
The last bit of new functionality in the manifest that I worked with is the License and Release Notes. These are new fields that users see when they install the module. We were already including a copy of the license in our [DNN] 4 packages, but now we can link to that file and make sure that users explicitly agree to it before installing the module. We also keep release notes on our website that we can now show upon install, rather than making folks search for them.
So, at this point, I think I'm done with this process. However, I try to install, and see the following:
Tracking this down, I realized that I had deleted elements with default values in the <moduleControls> section of the manifest. I didn't want to have a <viewOrder> element making it seem like someone was specifically setting that value, when really we don't care, it's just a default. Well, one of the elements I deleted was <controlKey> from the default module control. This is how our [DNN] 4 manifest looks, since the default module control doesn't have a key assigned. Looking at the error, it looked like that was no longer an acceptable practice, so I added a <controlKey/> to that <moduleControl> entry, and it worked like a charm. And, really, that makes sense. I care that <controlKey> is empty, I'm not just accepting the default value for lack of a better value, I'm actively choosing to use an empty <controlKey>.
So, those are the hassles, issues, and features that I encountered while creating a [DNN] 5 package for our module. Hopefully this'll give you some better understanding of some of what's involved, and get you more quickly around those obstacles that I ran up against.
[Cross-posted from http://www.engagesoftware.com/Blog/EntryId/194/Packaging-Modules-for-DotNetNuke-5.aspx]
