Community   »   Forums
RSS Feed Available AddThis - Bookmarking and Sharing Button Printer Friendly

PrevPrev NextNext

Are you sure you want to buy that module? - Part II

by Will M on 13 Sep 2008 03:06 PM

This is a follow up to my original article, "Are you sure you want to buy that module?

There have been quite a few new modules released on Snowcovered and the DotNetNuke Marketplace recently.  A lot of these modules are also coming from developers that are new to the market.  While I think this is great for the overall growth of DotNetNuke, you still need to be cautious and do your homework before you install any module.  Especially, when you see FREE or FREE Trial, it can make it all that much easier for you to cause problems in your DotNetNuke installation.  I highly recommend having a test environment for installing modules.  Even if you need to setup another basic DNN site with your hosting provider, it may save you headaches later on down the road. 

Another trend I have noticed in the DotNetNuke market is the use of third-party controls within commercial modules.  These controls could be from Telerik, ComponentArt, CuteSoft, XHEO, NeatUpload or others.  Their are several reasons why a developer may choose to use third-party controls when building a module they are going to sell.

  • Most of the work is already done for you. 
  • The control package may already include an attractive UI.
  • The developer can look to the control vendor for support when bugs or problems arise.
  • Ease of use - most of the controls can help you build a module in just a few minutes.
  • The control may offer funtionality in an area where the developer lacks experience.
    1. Let me start off by saying that Active Modules owns multiple subscription licenses for the Telerik and ComponentArt control suites.  We also use some of these controls in our Active CRM application.  They are fantastic products. 

      What's wrong with modules using third-party components?  Nothing, when they are used properly and efficiently.    However, I have yet to see this done by another vendor within DotNetNuke.  That means you are going to run into major problems with modules that rely on third-party components that aren't packaged properly.  Let's take a closer look at some of the problems.


      Problem 1: Installation Package Size

      The default ASP.NET upload size is 4 megabytes (MB).  A module that exceeds this size will have to be sent to the server using FTP and then manually installed by DotNetNuke.  Now, you can also increase the default upload size.  That still doesn't mean you are going to be able successfully install a module that is 6 MB in size. Chances are the DNN installer will timeout during the process.  

      Why is the install package so large?  Simple, these third-party components include all of their controls in one or more assemblies (.dll files).  They also may use images, scripts and other files that your module may never use.  Most people are looking for how to speed up DotNetNuke.  Do you really think you need all of that extra overhead that isn't even being used?

      Problem 2: Conflicts with other modules

      Let's say that you have a site that uses an e-commerce module that you bought a few months ago.  You have no idea whether it uses a third-party component or not.  All you know is that it is running great and you are selling products.  You get the weekly Snowcovered "What's New" email and see this great new module you want to try.  You download it, install it and KABOOM!!  Your e-commerce module is now dead, but your new module is working fine.  You think it may have been caused by the new module you installed, so you unistall it.  This makes problems even worse.  Now you contact the vendor of your e-commerce module, but it's after hours and might be several hours before you get in touch with the vendor.  In the meantime, your site is down and you are losing money.  I have seen way to many postings of this exact scenario.  Sound familiar? 

      What happened in this scenario?  Developer A used Version 2.0  and Developer B used Version 3.0 of the same third-party component.  Version 2.0 and Version 3.0 have the same exact filename.  When you installed the new product from Developer B this replaced Version 2.0 from Developer A.    The easy solution would be for Developer A to update to Version 3.0.  That may not be an option for Developer A.  Keep in mind most of these third-party components are licensed based upon an annual subscription that could be $600-$2000+ per year.  Developer A may no longer have a subscription and not be willing to renew. Even worse, Developer A may no longer be in business.


      Problem 3: Browser Updates and related issues

      This is really more specific to controls that are UI based.  What happens when a new browser is released or an update comes out that causes javascript or css problems?  If the problem is with a third-party component that the module you purchased is using, not only do you have to wait for the vendor to release a patch, that vedor has to wait for the vendor of the third party component to release a patch.  Don't count on getting that patch within 24 hours.


      Problem 4: Improper Licensing

      This probably may not be a big concern to most of you, but most of the third-party controls have very strict policies for licensing and redistribution.  You just have to be careful when you are building your DotNetNuke solution around a module that may not be using properly licensed third-party controls.  There are a couple of them out there already.



      What should you do?

      Get in the habit of asking module developers if they use 3rd party components.  Ask them if they have tested their module with any of the other modules that your site may rely upon heavily.  Find out what components they are using and why.  If it doesn't offer significant funtionality, could you find an alternative solution that doesn't use a third-party component? Finally, test test test and test again.  Keep in mind, testing just doesn't include how does the module function, but also does it play well with others.


      If you happen to be a commercial module developer that uses third-party controls and have successfully avoided these problems, then please leave a comment and I will gladly give you proper credit.

      For the record, here is a list of how we use third-party components in our DotNetNuke Modules.
      Active Forums: FreeTextBox converted to Active Editor
      CSharpFormat for color formatting code. 
      Active Profile: NONE 
      Active Messaging: NONE 
      Active Purchase:  NONE 
      Active Cases:      NONE 
      Active Compare:  NONE 
      Active CRM DNN Modules: NONE
      Will Morgenweck
      Active Modules

      0 Comments for Are you sure you want to buy that module? - Part II

      Active Forums 4.2