Contents tagged with Engage Modules
-
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.
-
Engage: Rotator 2.0
-
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]
-
Engage: Events 1.1
The first major update for Engage: Events has been released! Engage: Events is the event management module for [DotNetNuke] from Engage Software.
Many of the users of the 1.0 version of Events wanted to display a small, simple list of events in a prominent place on their site, like the home page. To address this scenario, we created three new templates that look great in a smaller pane, and present a simpler view of the events.
We also recognized that many of our users needed to have access to the list of attendees outside of the website itself. The responses list is now exportable to Excel or as a comma separated values (CSV) file.
One of the more common requests from our users is to limit the number of registrants to an event. This is especially important when you are scheduling classes or other activities with limited seating. You can now set a registration cap for your events, and, if you'd like, provide a custom message to the user if they want to register after the event has filled.
We've put a lot of care and love into this release, and we hope that it makes your event management simple, fun, and more effective. Take a test drive with the new features, let us know what you think and what you'd like to see next, and then buy it for your site.
-
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.
-
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!
-
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]
-
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]
