Please set me straight on DotNetNuke
-
I have used DNN for a few years now. It is a very fast way to get a site up and going. While in the past, it was a bit rough at times getting setup, nowadays it is pretty simple. You can even host multiple sites with one install of DNN on a single IP. That said, it depends on what type of site you want to have and if the client wants to provide content or make modifications without having to hire someone to do it all the time. You can edit any of the content from within a web browser so it is easy to rearrange or make modifications by the client. It comes with user management built in with email verifcations and now even OpenID. You can run a private membership site, a public membership site or both. It is very simple and comes at zero effort per site to setup memberships. Membership is can also be role based can be customized. Much of DNN uses a provider model so if you do not like the way a part is handled, you can simply swap out a new provider and you are off and going. DNN is basically structured where pages are built by added a number of different modules on a page. They have a number of modules that come with the system which includes things such as Forums, Blogs, Gallery, Resources, etc. All of these you simple drop on a page, set any configuration it may need (all in the web browser) and you are done. WIth DNN it is possible to setup a site that has a blog, forums and file resource center where part or all is membership based, within less than an hour. It is fairly easy to build your own modules to add to sites. There are a number of free resources available. There is also Visual Studio templates that make it a no-brainer. The largest problem I see about DNN is the performance is not as good as a stand along ASP.NET web application that a developer would build. Of course, if the site is not going to be heavily loaded (such as running hundreds of sites on a single server or large amounts of traffic), DNN works quite well. I would not use DNN for every site and at times it can be just as easy to build a normal web application if you do not plan to have many features. With all that DNN gives you along with the ease of clients being able to add / modify and remove content, it is a great solution. So, do you want to shave a fraction of a second off a page load and spend weeks to months builing your own and spend a little time getting use to DNN and then be able to knock out sites in hours. I will warn you though, there is a little overhead at the beginning getting use to t
We've been using it for a while now, from version 2 to the latest 4.8 version that we're testing. It's definitely bloated, it's slow at times, and a bit of a learning curve to configure correctly. That being said, it's fairly easy to get a content driven site out there to support a lot of internal users. The one thing we found is that cutting off access or responsibility to departments ended up in IT doing a lot of work. Delegate responsibility to department heads for getting their own content updated and out there and you'll have a lot better time of it. There is a lot to what Rocky and some of the others said. Finding help is a lot of hunting, and truthfully, their forums are kind of stinky. All in all, it's a lot of document and content management with a LOT of iFrames that I built custom apps in VS and generated apps from Iron Speed Designer - which I recommend. Good Luck! :laugh:
-
I just read a couple of posts that "nuked" DotNetNuke. I'd appreciate some substantive feedback about the drawbacks as I have been asked to use the 4.x framework to develop a site for a client. I just downloaded it this past weekend and have spent all of two hours with it so I'm hoping you all can save me some time if it's the wrong way to go. I'm more interested in architectural and business drawbacks than "real programmers do (or don't do) such and such..." My first impressions are that DNN can save me man- months of development time, but I'm concerned so far about the effort that would be required to customize it. If there are serious drawbacks, I'll need to be able to articulate them to the client and make a business case for the added development time. Thanks in advance.
I worked on four major DNN projects using version 3 and early versions of 4. That was enough for me, I doubt that I will ever use it again. I haven't looked at it since version 4.3 so some of my criticism may be outdated. It really depends on the business goals. DNN is a portal framework. It is not a CMS. It is not an application framework. If you need to build a portal, then DNN may be a good fit. I tried to use DNN as both a CMS and a general web application framework and the results were not good. As a CMS, DNN lacks several key features such as versioning, auditing, approval chains, etc. There is a "Managed Content" module that you can purchase which provides these features at the module level, but nothing is built in to provide these features on a page or system-wide level. As a web application framework, I found DNN to be too inflexible. It was just too high of an abstraction to do some of the things that we wanted to do. Writing custom modules is not difficult, but if you need to do something that doesn't fit into the DNN paradigm of pages and modules then you quickly fall into rough waters. I have had much more success using MonoRail/ActiveRecord from the Castle project as a web application framework. Another major pain point with DNN was producing valid xhtml and html output. It was possible, but required making changes to the core and almost any module that you wished to use. Once you go down this path, you are basically creating your own fork of the DNN project and maintenance becomes a burden. DNN is also very complex. I would think twice about applying it to smaller web projects that do not need such a large, complicated solution. Overall, I wouldn't dismiss the DNN project, but I would look carefully to see if really meets your business goals. If your business goals line up with DNN, then I think it can be a real time saver. Regards, Eric
-
- Documentation is YEARS behind the current version. 2) If you want *real* help, you have to buy one or more books. 3) It's a slug once you get it running with any substantive content. 4) The forums on the DNN home page won't do you any good because they're heavily moderated. Your question won't show up for DAYS. 5) It started out as a Microsoft project (that fact alone should be enough to make you look for something else).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
- Documentation is YEARS behind the current version
Yes, this is a true statement, however, many DotNetNuke community members such as myself maintain documentation that is of high quality and makes it easy to use.
John Simmons / outlaw programmer wrote:
- If you want *real* help, you have to buy one or more books.
Personally this is not true either, the current books on the market are way too far behind. If you need support, you need to use the DNN forums, or a private forum that many of the community members provide. Or optionally you can elect for a support plan from the DotNetNuke Corporation OR third-party providers.
John Simmons / outlaw programmer wrote:
- It's a slug once you get it running with any substantive content.
If you have not configured DNN correctly it will be slow, however, as long as the system is properly configured AND you selected modules that have performance in mind you will notice great performance, even on high scale systems. I have worked with many clients with "slow" DNN systems and a few configuration changes later they had a very quick site that was able to handle anything needed.
John Simmons / outlaw programmer wrote:
- The forums on the DNN home page won't do you any good because they're heavily moderated. Your question won't show up for DAYS
There are MANY problems with the DotNetNuke.com forums, however, moderation is typically under 1 hour, and goes away after activity on the site. You also have other support options. the one thing I will strongly note to everyone is that CURRENTLY e-mail notifications do NOT work from the DotNetNuke.com forum. This has been one thing that has driven traffic to my sites a lot recently.
-Mitchel Sellers MCITP, MCPD, MCTS CEO/Director of Development IowaComputerGurus Inc. http://www.mitchelsellers.com
-
I just read a couple of posts that "nuked" DotNetNuke. I'd appreciate some substantive feedback about the drawbacks as I have been asked to use the 4.x framework to develop a site for a client. I just downloaded it this past weekend and have spent all of two hours with it so I'm hoping you all can save me some time if it's the wrong way to go. I'm more interested in architectural and business drawbacks than "real programmers do (or don't do) such and such..." My first impressions are that DNN can save me man- months of development time, but I'm concerned so far about the effort that would be required to customize it. If there are serious drawbacks, I'll need to be able to articulate them to the client and make a business case for the added development time. Thanks in advance.
I have replied to a few other posts here but thought I would give a more solid response to the orig. question. First of all I am an active member of the DotNetNuke development community and use DNN for both my day job and most of my consulting projects for clients, so I have had vast experience using DNN in various levels of implementation from small sites to large sites. I will leave the development discussions pretty much alone, but DNN is built using VB.NET for the core, but you can use C# or VB for any extensions (Modules, Authentication Providers, Skin Objects) that you need to have custom built and everything plays very well together. The first and foremost item that is of business related process is that as people pointed out above documentation from DotNetNuke Corporation is WAY out of date, last I checked it was based on 4.4.1 and we are currently on 4.8.2 for current releases. This is an issue if you are not willing to look to other places for assistance. I run a blog site at MitchelSellers.com where I provide documentation on DNN fucntionality, installation, upgrades and other items of that nature. Many other community members do contribute this type of information as well. This is a stumbling block as to PROPERLY leverage DNN you must fully understand the configuration of the site and you MUST make changes to the defaults to obtain the best performance. Once you learn DNN and how to administer it you can leverage it as a high power tool that can save you a LOT of time. However as it was mentioned above, there are certain times that DNN is just not a right fit, but that is really something that must be determined on a case by case basis. DNN performance as I mentioned before is dependent a lot on the settings/configuration inside DNN but additionally as it is mentioned above the hosting provider has a lot to do with it as well. I personally use 3Essentials hosting (Referral link available on my site), but I also recommend PowerDNN. Both of these providers offer shared and dedicated plans. There are MANY high availability, high traffic websites running on DNN as well, a few examples of these are the Austrailian Football League (http://www.afl.com.au I believe). It all comes down to knowing DNN and knowing what hosting is needed for your loads. In terms of customization DNN offers great abilities here as well, you can customize all aspects of a DNN site, some with modules, authentication providers, skins, skin objects and
-
As with anything, the perception of DNN will vary greatly depending on many factors. I have invested allot of hours into setting up and managing a few DNN based portals (mostly 3.X versions). * My #1 complaint is/was that page load/display performance was very bad, even on powerful hardware. * We also came across a couple major security holes that caused me at least one long night. * Setup/config can be painful, but I've heard that its been improved in V4+. * The documentation is woefully lacking in almost every regard. * Not sure if this is true with version 4, but version 3 did not really support web parts which is the ASP.NET/Sharepoint way of adding components. * Modules were easy enough to develop as long as there were no interdependencies. If you tried to build modules that were inter-dependent in some way, it was much harder and required hacks. * Lacks personalization capabilities (again, not sure about V4). * Code was in VB.NET (yuck!) On the plus sides, once it was setup adding content is fairly easy as long as content was supported by the provided modules. Also, deploying to sharted hosting environments is very doable. Oh yea, there are allot of 3rd party modules available for DNN available for free and at nominal cost. Remember the saying: "you get what you pay for". My experience with the "inexpensive" 3rd party modules was that they were buggy, slow and poorly written. Depending on your needs, Sharepoint Services may be a good fit. Performance is pretty good, module development is straight-forward, documentation is OK, setup is painless. The biggest drawback to Sharepoint Services IMO is deployment onto shared-hosting environments.
Matt Gullett wrote:
My #1 complaint is/was that page load/display performance was very bad, even on powerful hardware.
A lot of this was resovled with DNN 4.4.1, and other items could be resolved with configuration changes
Matt Gullett wrote:
We also came across a couple major security holes that caused me at least one long night.
A very detailed review was also done I believe around DNN 4.4.1 that addressed many of the blatant holes that existed in 3.x versions. THis is a major reason that I try to move my clients to at least 4.4.1.
Matt Gullett wrote:
Setup/config can be painful, but I've heard that its been improved in V4+.
This is still painful, but if you find the right documentation it isn't that hard.
Matt Gullett wrote:
Not sure if this is true with version 4, but version 3 did not really support web parts which is the ASP.NET/Sharepoint way of adding components
Extensibility with the DNN core is done still via DNN modules and not via WebParts, however there are third party modules out there that support WebParts.
Matt Gullett wrote:
Modules were easy enough to develop as long as there were no interdependencies. If you tried to build modules that were inter-dependent in some way, it was much harder and required hacks
This is not true, and really wasn't true with 3.x depending on what you are looking for. Intermodule Communication is supported via the two interfaces, and using the WAP (4.x) development model compiles you modules so you can have references etc.
Matt Gullett wrote:
Code was in VB.NET (yuck!)
I personally don't see this as an issue, you can customize anything except for the core using C# if you want, so it isn't anything major.
-Mitchel Sellers MCITP, MCPD, MCTS CEO/Director of Development IowaComputerGurus Inc. http://www.mitchelsellers.com
-
John Simmons / outlaw programmer wrote:
- Documentation is YEARS behind the current version
Yes, this is a true statement, however, many DotNetNuke community members such as myself maintain documentation that is of high quality and makes it easy to use.
John Simmons / outlaw programmer wrote:
- If you want *real* help, you have to buy one or more books.
Personally this is not true either, the current books on the market are way too far behind. If you need support, you need to use the DNN forums, or a private forum that many of the community members provide. Or optionally you can elect for a support plan from the DotNetNuke Corporation OR third-party providers.
John Simmons / outlaw programmer wrote:
- It's a slug once you get it running with any substantive content.
If you have not configured DNN correctly it will be slow, however, as long as the system is properly configured AND you selected modules that have performance in mind you will notice great performance, even on high scale systems. I have worked with many clients with "slow" DNN systems and a few configuration changes later they had a very quick site that was able to handle anything needed.
John Simmons / outlaw programmer wrote:
- The forums on the DNN home page won't do you any good because they're heavily moderated. Your question won't show up for DAYS
There are MANY problems with the DotNetNuke.com forums, however, moderation is typically under 1 hour, and goes away after activity on the site. You also have other support options. the one thing I will strongly note to everyone is that CURRENTLY e-mail notifications do NOT work from the DotNetNuke.com forum. This has been one thing that has driven traffic to my sites a lot recently.
-Mitchel Sellers MCITP, MCPD, MCTS CEO/Director of Development IowaComputerGurus Inc. http://www.mitchelsellers.com
I'm ussing DNN for last several years and I agree 100% with Mitchel.
-
I just read a couple of posts that "nuked" DotNetNuke. I'd appreciate some substantive feedback about the drawbacks as I have been asked to use the 4.x framework to develop a site for a client. I just downloaded it this past weekend and have spent all of two hours with it so I'm hoping you all can save me some time if it's the wrong way to go. I'm more interested in architectural and business drawbacks than "real programmers do (or don't do) such and such..." My first impressions are that DNN can save me man- months of development time, but I'm concerned so far about the effort that would be required to customize it. If there are serious drawbacks, I'll need to be able to articulate them to the client and make a business case for the added development time. Thanks in advance.
You're going to be behind and sacrifice a lot of new technologies like Linq and new versions of the .NET Framework until they decide to port the core. You sacrifice a more standard set of technologies like MasterPages for the DotNetNuke implementation of skins. I recommend you listen this MS podcast by DotNetNuke founder Shaun Walker himself for more info. http://download.microsoft.com/download/4/E/F/4EFC8904-82E7-4BA2-A7BC-F6759FAFF9FE/1032359088.mp3[^]
-
Matt Gullett wrote:
My #1 complaint is/was that page load/display performance was very bad, even on powerful hardware.
A lot of this was resovled with DNN 4.4.1, and other items could be resolved with configuration changes
Matt Gullett wrote:
We also came across a couple major security holes that caused me at least one long night.
A very detailed review was also done I believe around DNN 4.4.1 that addressed many of the blatant holes that existed in 3.x versions. THis is a major reason that I try to move my clients to at least 4.4.1.
Matt Gullett wrote:
Setup/config can be painful, but I've heard that its been improved in V4+.
This is still painful, but if you find the right documentation it isn't that hard.
Matt Gullett wrote:
Not sure if this is true with version 4, but version 3 did not really support web parts which is the ASP.NET/Sharepoint way of adding components
Extensibility with the DNN core is done still via DNN modules and not via WebParts, however there are third party modules out there that support WebParts.
Matt Gullett wrote:
Modules were easy enough to develop as long as there were no interdependencies. If you tried to build modules that were inter-dependent in some way, it was much harder and required hacks
This is not true, and really wasn't true with 3.x depending on what you are looking for. Intermodule Communication is supported via the two interfaces, and using the WAP (4.x) development model compiles you modules so you can have references etc.
Matt Gullett wrote:
Code was in VB.NET (yuck!)
I personally don't see this as an issue, you can customize anything except for the core using C# if you want, so it isn't anything major.
-Mitchel Sellers MCITP, MCPD, MCTS CEO/Director of Development IowaComputerGurus Inc. http://www.mitchelsellers.com
Thanks for the info. I'm glad to hear that some of the issues I encountered may have been dealt with. The performance issue was a major problem for me even on dedicated equipment. The security problems could have caused very great damage to a site that maintained any personal information on members. Hopefully those issues have been resolved. In terms of inter-module communications, yes, there was some support in V3.x, but it was buggy and didn't support a number of modes of operation that I required. In my speicfic situation I had to build what amounts to being an application within DNN modules. DNN just wasn't designed to support my needs well. I have nothing against DNN and I think it has it's uses. I no longer use it in a production environment due to the earlier problems I encountered and other changes in my work-function. Good luck in your endeavours, and thanks for the information.
-
I just read a couple of posts that "nuked" DotNetNuke. I'd appreciate some substantive feedback about the drawbacks as I have been asked to use the 4.x framework to develop a site for a client. I just downloaded it this past weekend and have spent all of two hours with it so I'm hoping you all can save me some time if it's the wrong way to go. I'm more interested in architectural and business drawbacks than "real programmers do (or don't do) such and such..." My first impressions are that DNN can save me man- months of development time, but I'm concerned so far about the effort that would be required to customize it. If there are serious drawbacks, I'll need to be able to articulate them to the client and make a business case for the added development time. Thanks in advance.
For starters, I hope your client likes one of the already-existing themes that are available (most good ones for a price) on the 'Net, because creating your own skin/layout in DNN is an absolute nightmare.
Grim (aka Toby) MCDBA, MCSD, MCP+SB SELECT * FROM users WHERE clue IS NOT NULL (0 row(s) affected)
-
You're going to be behind and sacrifice a lot of new technologies like Linq and new versions of the .NET Framework until they decide to port the core. You sacrifice a more standard set of technologies like MasterPages for the DotNetNuke implementation of skins. I recommend you listen this MS podcast by DotNetNuke founder Shaun Walker himself for more info. http://download.microsoft.com/download/4/E/F/4EFC8904-82E7-4BA2-A7BC-F6759FAFF9FE/1032359088.mp3[^]
What do you mean by "they decide to port the core?" We are using DotNetNuke v4.8.2 with Visual Studio 2008 and .net framework 2.0 & 3.5, LINQ and LINQ to SQL, running under IIS 7 (Classic and Integrated Pipeline) right now. Not tomorrow, not next week, today. How many other projects will work in this advanced .net scenario? Like I said in another post, MasterPages came after DNN skins. Gee, what a great idea. The DNN core may be based on best practices but that does not leave you behind or sacrifice any new technology in any way. Even C# developers can use DotNetNuke if they know what they are doing. :laugh:
Dwayne J. Baldwin
-
What do you mean by "they decide to port the core?" We are using DotNetNuke v4.8.2 with Visual Studio 2008 and .net framework 2.0 & 3.5, LINQ and LINQ to SQL, running under IIS 7 (Classic and Integrated Pipeline) right now. Not tomorrow, not next week, today. How many other projects will work in this advanced .net scenario? Like I said in another post, MasterPages came after DNN skins. Gee, what a great idea. The DNN core may be based on best practices but that does not leave you behind or sacrifice any new technology in any way. Even C# developers can use DotNetNuke if they know what they are doing. :laugh:
Dwayne J. Baldwin
I meant what I said, when there is a major revision of .NET you will have to wait until DotNetNuke updates it's core. Try running DotNetNuke written in version 1.1 of the Framework in a 2.0 site...doesn't work. Also it's impossible to include C# code files in a C# module. You have to create a separate project/dll for your module if you want a C# code file that's not a code-behind file. That's ton's of fun. Just because skins came before MasterPages doesn't make them better. It reminds me of Apple user's gripes that Apple had a GUI before Microsoft. Who cares!? I means seriously, how relevant has Apple's PC market been just because it did something first?
-
I meant what I said, when there is a major revision of .NET you will have to wait until DotNetNuke updates it's core. Try running DotNetNuke written in version 1.1 of the Framework in a 2.0 site...doesn't work. Also it's impossible to include C# code files in a C# module. You have to create a separate project/dll for your module if you want a C# code file that's not a code-behind file. That's ton's of fun. Just because skins came before MasterPages doesn't make them better. It reminds me of Apple user's gripes that Apple had a GUI before Microsoft. Who cares!? I means seriously, how relevant has Apple's PC market been just because it did something first?
Applications should not be affected by major .net revisons? MasterPages work with .net 1.1? Who said better? ASP.net did not have MasterPages. DotNetNuke had skins. Microsoft just borrowed the idea, just like Apple borrowed the GUI from Xerox PARC. Don't forget Visual Studio Web Application project (WAP) vs. Web Site Project (WSP). We are all learning here, including Microsoft.
Dwayne J. Baldwin
-
jond777 wrote:
If there are serious drawbacks,
Visual Basic. 'nough said. ;P
only two letters away from being an asset
My 20c worth... I have been using DNN for a few years now. On the basis that DNN was a bit slow and bloaty, the last site we built was done in pure asp.net. Now the customer wants to edit content themselves, and make it multi-lingual, and add pages themselves, and make some page content context &/or login sensitive... In short, we should have used DNN. If your customer is very likely to expand the specs, and your development team use microsoft tools, DNN is still a very good choice. You don't have to custom write modules to handle all the things the base system doesn't do, there are heaps of free and commercial modules already available online. Note about VB: if you use C#.net to write the modules, they work just the same! Trevor Mullen. Senior Software Developer Datamax Holdings P/L Australia.
-
Applications should not be affected by major .net revisons? MasterPages work with .net 1.1? Who said better? ASP.net did not have MasterPages. DotNetNuke had skins. Microsoft just borrowed the idea, just like Apple borrowed the GUI from Xerox PARC. Don't forget Visual Studio Web Application project (WAP) vs. Web Site Project (WSP). We are all learning here, including Microsoft.
Dwayne J. Baldwin
That's what I'm saying though. Nobody has a Xerox PC, and very few people have a Mac. It's great that they did what they did, but their own implementation never became mainstream. If Microsoft knows anything, they know business. They know how to be profitable which helps developers along the way. My two biggest problems with DotNetNuke, is that I was learning a tool set that would not be very valuable to me when, I could have been concentrating on other areas. The other issue is that it seemed to reverse the headache points in building applications. It made everything that was difficult very easy, but it made the simple things very difficult.
-
I just read a couple of posts that "nuked" DotNetNuke. I'd appreciate some substantive feedback about the drawbacks as I have been asked to use the 4.x framework to develop a site for a client. I just downloaded it this past weekend and have spent all of two hours with it so I'm hoping you all can save me some time if it's the wrong way to go. I'm more interested in architectural and business drawbacks than "real programmers do (or don't do) such and such..." My first impressions are that DNN can save me man- months of development time, but I'm concerned so far about the effort that would be required to customize it. If there are serious drawbacks, I'll need to be able to articulate them to the client and make a business case for the added development time. Thanks in advance.
We have about 20 small to medium sized web sites built with DotNetNuke running on our server and have very few problems with them. It's not the fastest framework in the world, but it's flexibility and ease of use make up for it. I can set up a new DNN web site in just a couple of hours with blogs, forums, faqs, galleries, newsletters, subscriptions and tons of other features built right in. But the real selling point is that our customers LOVE being able to maintain their own web sites without extra software, without FTP, and without extensive knowledge of HTML or other web technologies. That's what DNN is really about, and that's where it really comes through. If you want speed, nothing beats plain text, but you won't attract much interest that way.
Meddle not in the affairs of dragons, For you are crunchy, and good with mustard.
-
For starters, I hope your client likes one of the already-existing themes that are available (most good ones for a price) on the 'Net, because creating your own skin/layout in DNN is an absolute nightmare.
Grim (aka Toby) MCDBA, MCSD, MCP+SB SELECT * FROM users WHERE clue IS NOT NULL (0 row(s) affected)
There are literally thousands of skins available, so your customer is likely to find one they like. If not, I've created more than a half dozen skins/layouts for DNN web sites, from simple to fairly complex, and it really wasn't that difficult. All it takes it some knowledge of DHTML and CSS, reading the skinning documentation, and browsing through a couple of existing skins to get an idea how it's done.
Meddle not in the affairs of dragons, For you are crunchy, and good with mustard.