Please set me straight on DotNetNuke
-
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.