Related
Can one create a good e-Commerce application using a tool like DNN merged with some ready made shopping cart? I did not use DNN before, but I think, it will be tough thing to do, I think I will face troubles with performance and maintainability.
Further I think it is almost impossible to convert asp.net web application to DNN, this will wast more time even if I throughaway the UI layer.
Probably it is good to create a small e-commerce application using DNN, that kind of applications that costs 3000 USD, created for once, and not likely to extended.
Talk to me about this.
Thanks
Can one create a good e-Commerce application using a tool like DNN merged with some ready made shopping cart? Yes... But you'll be better served by just using some of the off the shelf cart modules for DNN.
Further I think it is almost impossible to convert asp.net web application to DNN, this will wast more time even if I throughaway the UI layer. This entirely depends on your skill level in writing DNN modules and the needs of the application. No way to even answer other than to say: Why bother? If the application is done and ready to go, there's probably not much of a reason to rebuild it within DNN.
Probably it is good to create a small e-commerce application using DNN, that kind of applications that costs 3000 USD, created for once, and not likely to extended. There are numerous free and open source eCommerce modules for DNN. There are also several good paid for eCommerce modules. Why bother creating your own? Especially if you don't have much experience in writing modules for DNN...
I'm not clear on what your goal is. Plenty of people operate e-commerce sites using DNN. If by large you mean you are looking to take on Amazon then DNN is not for you.
In my opinion DNN's strength is around content management, if you need significant content management and commerce functionality then DNN is likely a good choice. If your primary concern is commerce functionality with little or no other content management needs, then I would look to something more focused on commerce.
It is very possible to convert existing apps to DNN. You will need some understanding of how module development and skinning in DNN works, and then you will find that much of the existing code can likely be copy paste into a module. Once you understand how/when skins and modules are run you will find you can drop in pretty much any ASP.Net code and expect it to work. Of course to take advantage of DNN core features (membership and permissions are common items) you will need to use the DNN APIs. Also it is possible to run DNN side by side with an existing application under the same website.
To me it makes sense to build on DNN if your application will receive significant benefit from off the shelf core and extension module functionality. If you can't remove significant features from your development schedule by using DNN, then you probably shouldn't use DNN.
I haven't found the currently available DNN E-Commerce modules to be good enough to run a site that is really focused on E-Commerce. You should make sure NBStore (a free an Open Source Module) won't meet your E-Commerce as it is very well built but isn't particularly feature rich. Catalook, while feature rich, is terribly written, and I highly recommend avoiding it. Most the other available modules don't have all the needed features for a serious online store.
We've been using AbleCommerce when E-Commerce is the primary focus. AbleCommerce is feature rich, very well built, and relatively easy to customize and extend. We have done basic integration between AbleCommerce and DNN where we used DNN for the main site and AbleCommerce for the E-Commerce piece. AbleCommerce just ran as a Virtual Directory within the DNN site. We did not integrate login/user functionality which was fine for the site. If you truly need the capabilities of DNN, this may be a good way to go.
I need to develop a newspaper site in Drupal, I've already played around with Drupal a little, and I think I know which modules would best suit my purposes. Naturally, one of the modules I'll be needing to use most is Views, but I have a couple of questions:
Because this is a content-intensive site, I was wondering if using 5-6 views on each page to generate node teaser + thumbnail lists would impact performance adversely?
I am a designer with significant front-end development experience. Like I said I've played around with Drupal quite a bit and other than running into a few hurdles which I eventually overcame, for the most part I was able to get it to do what I needed it to. Having said that, does one also need strong programming skills to fully develop a site in Drupal?
Thank you very much for your help!
Jane
Views offers caching and Drupal also has block caching, which should help you improve performance. The SQL that Views generates is never as good as handwritten SQL, but if you make simple Views, the SQL is actually quite good and not a performance problem (unless you have millions of page views).
If you can create the features you need, with modules from Drupal.org, you don't need strong developer skills. But you do need to know some PHP to make a Drupal theme which is what controls the layout of the site. It will also be a great help, in understanding the Drupal theming system, but not a requirement.
First off, check out openpublishapp.com for a Drupal distro that is made for publishers from the ground up, it's pretty hot.
To answer your questions:
1) As far as performance and views goes, having 5-6 views on a page is a normal requirement for a drupal news site and the performance issues are usually handled by views/panel cache, and using a page cache like Varnish in front of a web server, Object caches like Memcached (for the DB) and opcode caches like APC...if you don't want to learn all that off the bat you should still be fine if your traffic isn't too intense (but go sign up at getpantheon.com for awesome hosting with all of that and the kitchen sink, and check out groups.drupal.org/pantheon)
2) If the functionality exists by way of core/contrib modules, to fully develop a site for the most part one only needs to understand enough PHP to theme, and often with starter themes like Fusion, and some of the others you hardly even need that, just an understanding of how they work and are extended (which is well documented). That said, if you want functionality that doesn't exist, you'll have to code it, or have someone code it for which strong programming skills are desired, but not necessarily required :)
Even I recommend the use of the OPENPUBLISH - https://www.acquia.com/solutions/publishing
On top of to this you can make an efficient usage of
1. APC - PHP byte-code caching
2. Drupal Caching - block/template/view level caching
3. Boost - Caching module which doesn’t need any external tools
4. Varnish - HTTP accelerator
5. Memcache - Data intensive content.
Apart from this you will also need to think effectively on deciding on DEPLOYMENT ARCHITECTURE of the site - preferably Acquia or Amazon environment.
Learning curve may vary depending on your current skills in PHP or Drupal. Usage of already established distribution like OPENPUBLISH may help you to minimize the dependability on too much custom coding.
I've started to wondering whether ASP.NET Webforms/MVC even have a place in the web developers toolbox anymore... It seems that CMS systems like Umbraco have replaced the web developers job. Yes I know that those CMS systems are built with ASP.NET Webforms/MVC - however is there even any reason for learning those things if all you gonna do is to use a CMS system anyway? - Also I cant find any situation where a CMS system can be replaced by your own web application.
My question is therefore: Is there any reason for learning Webforms/MVC when using a CMS?
EDIT:
My question might be more like: When should I use a CMS, and when should I go and build my own web app?
The problem with CMS solutions, and I mean all CMS solutions (not just Umbraco, or other .NET solutions, but in any language) is that you will always pay a price for using them. You may gain more from the time-savings afforded by using the CMS, but there are trade-offs to consider:
You will sacrifice a great deal of flexibility
You could pay a significant performance penalty. Many CMSs load a large amount of modules and code to service every request, and much of this is not relevant to a particular page function. (though some CMSs are more monstrously heavy than others!)
The future of your project is tied to yet another vendor, and their own choices
Very often, you rule out the possibility of using other databases that might have better fit your customer's needs (Umbraco doesn't support PostgreSQL, Kentico only supports SQL Server)
Once you start using a CMS you will be tied into satisfying the architectural decisions and API of the CMS framework, and you could eventually be backed into a corner.
This can be particularly problematic if your 'site' is more of a web application than a pure content delivery site. In such cases it can make more sense to choose to build using the full flexibility of the web application framework, rather than risk getting backed into an architectural corner.
On the other hand, if you are building a web site that has potentially hundreds of pages, with a lot of user-contributed content and is much less of a web application, then often a CMS is the way to go, and makes a lot of sense. But remember, you now have two frameworks and two APIs to learn and manage (your platform's framework and the CMS framework).
Writing a CMS is like invading Afghanistan.
Everybody gets a turn but nobody wins.
I don't think that Stack Overflow could have been built with a CMS. Does that answer your question? =)
Update
To answer your updated question.
If you want a regular corporation web containing news, articles, forum etc: Go ahead and use a CMS.
If you need to build a more custom web site like stackoverflow, a web interface for a system or anything like that: Built it using MVC etc.
I personally use a CMS for our corparate website and a MVC framework to build user and administration interfaces for our products.
Not every problem needs a CMS. In the same way not every problem needs a bespoke MVC/webforms website. It depends on what your requirements are. You pick the technology to solve the problem.
Build vs buy is the hardest decision to make. As a developer build always looks best. You can do better than that pile of carp they want to buy. Nevermind that you're reinventing the wheel, axel, cart, etc. To users/management buy always looks best. They don't have to think to hard about what they want and can have it now, not 3 months later after you write it. They forget it'll cost the same again to customise & make it impossible to upgrade.
I'll stop ranting now.
Umbraco is a pretty bare minimum CMS. To customize it (e.g. Version 7+) you'll need to know Heavy MVC, JSON, XML, Sql, etc.
In fact a Site built on Umbraco 7+ is entirely based on MVC views you set yourself and assign to SurfaceControllers (which are MVC controllers) and all you are really getting is the ability for users to edit things about your pages and have Umbraco manage it for you in a DB.
In short you still need experienced web developers to build a site on Umbraco, they just save a lot of time by not having to build the entire backend from scratch.
You use Umbraco to organize Document Types that define what Templates (MVC Views) are used for rendering different types of documetns (e.g. Web Pages) and then you built the template from the ground up with 100% control over the HTML, Css, and Javascript that get's output.
Imo Umbraco is more of a Framework like Django than a complete CMS.
Sure you can build a site in Umbraco and not customize anything, but it would be a pretty cheesey site.
The whole point to Umbraco is to give skilled .Net Developers a good platform for building a site on top of it, but they still have to build it.
Now sharepoint would be more of a complete CMS out of the box that you can do a lot with, but let's see a few problems with SharePoint...
Resource Heavy, eats 50+ Gig's to install
Eats 16 GB of ram just to boot it up (Sharepoint 2013)
Requires Sql Server 2008 R2 or equivalent (enterprise license, $$ chaching)
Requires Windows Server ($$chaching)
It's a monster basically, if all you need is a user editable blod platform... man what a waste of money. Foundation is free, but doesn't include things like the Blog Site Template, so you buy a server enterprise license ($$ big cachinge, 40,000$+ in some scenarios...)
Agreed. A CMS like Umbraco provides a (very) good out-of-the-box solution for the most basic applications. Any sort of specialized purpose is going to require additional programming knowledge. Anymore, though, and your major, if not primary need is going to be a good understanding of the business need. I think we're getting away from building the Legos themselves and on to building the neat toys with the Legos. Cheers!
A CMS (or similar application framework) will provide you with a lot of functionality out of the box, and many of them also have a good library of plug-ins. But you'll still need to write WebForms/MVC code if you want to add any custom features.
I have never used DotNetNuke before. I'm thinking about giving it a try to help me build websites, and I'd like to hear from other developers who are in a position to compare DotNetNuke with other CMS's/Web Application Frameworks.
I have used both DNN and Drupal to build fairly large, content-based sites. My focus is more on the production side... UI/themeing, module configuration, etc. I'm sold on Drupal, but there may be other choices that meet your needs just as well. I just happened to work with both systems in recent months.
Drupal's core taxonomy module gives you the benefit of creating a relationship between different kinds of content. If you have "article" and "video" content types, you can easily display data from both types based on the shared taxonomy terms. This is huge and something DNN lacks.
Drupal's hook system is also a big benefit when building your own modules or creating "sub-modules" to alter or add to the default functionality of an existing module. This allows you to customize functionality or take advantage of another module's functionality as your application runs. If you purchase a module for DNN, you will have to alter the module if it doesn't meet your needs. Once you do this, you will need to update it each time there's a new release that you would like to take advantage of. DNN modules seem to be more stand-alone solutions. For example, if a DNN module has a rating system, it's only a part of that solution. With Drupal, I can use the "5 Star" rating module in my forums, my blogs, my articles, my videos, etc. There's central configuration for it and I only theme it once.
The themeing layer in Drupal also gives you a large amount of flexibility in that process. My frustration with themeing DNN sites was that I was stuck working with the markup the developer used, with no option for altering the output without hacking the module. With theme hooks and function overrides, I can change the output from those modules to meet my needs (not completely sometimes, but enough), without touching the module code itself.
The biggest problem I had with DNN modules, including some of the most popular, was just a lack of documentation or discussions available for how to achieve your goal. While Drupal's forums can be hard to navigate and you might not always find the answer you are looking for, there are many outlets for gathering information. Honestly, using DNN made me appreciate the community approach of Drupal more.
I was left feeling that DNN would be fine for building sites with more basic needs. But for that, I would still choose something like WordPress or Joomla, considering they have much larger user bases and, in my opinion, are more sophisticated.
Hope this helps you some.
DNN is a pretty good .NET solution for CMS. If you want more flexibility, I would look at SiteFinity for .NET CMS systems. This is a very flexible and elegant CMS for .NET
If you venture out of .NET and want to look at PHP solutions, then DRUPAL, JOOMLA, and WORDPRESS are best solutions. Some comments about each:
WORDPRESS - Is the simplest and most elegant CMS to work with. Originally a blogging software, it has a super-easy user interface, although that also reads as more limited power and features. It's excellent for content driven websites and templates are easily built.
DRUPAL - Is very flexible and configurable, but I find it more complicated than the others. The Admin interface requires more programming knowledge to pull off and adding components and extras is a little more complicated. But, DRUPAL has been proven in the business and government world as a secure and reliable CMS.
JOOMLA - Is my personal favorite. It is also very powerful and I prefer the Admin. interface. Joomla allows for much flexibility and has the most user created modules and plug-ins out there. You have to invent near nothing with this one. I am biased in favor of Joomla, because I use it the most. That said, it has limiting factors against DRUPAL, such as user security features. But this is being fixed in the next upgrade.
Hope that helps as well.
I have development experience using both DNN and Drupal to build content-rich websites. My preference is Drupal for a number of reasons:
Development time-line was shorter; I was able to produce more in less time.
Drupal has a larger and more active developer community. More resources are available to aid in development.
DNN is not actually a CMS. It is only a framework; Drupal is a framework with a foundational CMS.
Drupal is easier to install.
DNN modules cost money; Drupal modules are free.
Actually, I put together some notes a while back when trying to understand the architectural differences between DNN and Drupal. Found those notes, they are here: DNN versus Drupal. Hope this is helpful.
I experienced a fairly high degree of frustration when working with DNN and I don't believe I am alone in that regard. About a year ago, ASPdotnetStoreFront abandoned their involvement with DNN calling it a "disaster to work with".
I am curious to know what piqued your interest in DNN and if you have a specific website project in mind. Regardless, I wish you success and I hope this helps.
I worked in a .NET development shop utilizing Kentico CMS. I agree, it is feature rich and stable. The API and DB are documented well. Overall, it is a great CMS. There is a limited free version: http://www.kentico.com/freecms.aspx
I'm testing out DNN right now. So far, so good, but I think it depends a lot on what you are using it for. I've only been looking at it for 3 days, but so far I do find the documentation lacking or outdated.
I evaluated many of the different Portal/CMS systems out there back in 2004 and DotNetNuke ended up being my choice and I've been very pleased with it, for everything but E-Commerce, ever since. DotNetNuke is endlessly extensible, easy to skin, easy for non-technical folks to update, has a great 3rd party eco-system, and the development team is very active and talented. There isn't a great Articles module in the core but there are several really good ones available from 3rd parties for a reasonable price.
I tried using Joomla a few years ago and hated it. Wordpress is good for a blog style site but doesn't have nearly the power or flexibility of something like DNN. I am intrigued by SiteFinity, Umbraco, and Kentico for sites where all that's really needed is a CMS, but not enough that I've bothered trying them over DNN.
Another good .NET solution - from what I've read - is Umbraco.
Take a look at Kentico CMS. It's commercial, but still affordable. In my experience from dozens of projects on both CMS, Kentico is much more feature-rich, stable and well documented.
We want to build a web application, that is specific to our domain, but also includes forums, blogs, etc in this application. Some integration points to Twitter and Facebook are also required.
There will also be a desktop application that connects to our web application for uploading data and downloading configuration and reports.
The question is, can we extend Drupal to host both the regular modules and our web application? (There will be business entities and their properties and daily data uploaded from the desktop application)
Or can Drupal be integrated with external applications? As an example, users and roles need to be the same and consistent across both. We may also want data from the web application searchable in Drupal.
I know this is a bit vague, but I cannot reveal more. I am very new to content management and I just wanted to know if someone has built this kind of application.
I try to rephrase what you wrote, just for you to check that I got your question right. You basically need to create a web application that:
Implements some of the standard functionality of Drupal
Have some custom functionality that should "blend into" the Drupal one (same users, same permissions, etc...)
Be able to upload/download content (or data) from desktop applications.
If I got you right, the short answer is: yes, you can do that with Drupal.
Now for the extensive one:
- Drupal has literally thousands of modules, so I expect you to get most of the things you want by simply installing the right combination of readily available modules.
- Of course, any custom functionality can easily be implemented in form of a module too (quite standard thing these days).
- The interaction with a desktop application is normally implemented via webservices rather than querying the DB directly. Drupal comes natively with a xmlrpc server and client, but you can scale up to SOAP - if you wish - via a couple of contrib modules.
Some additional thoughts:
If you choose to use Drupal, and you start from scratch, then you have to be aware you and your team will need to dedicate some time and effort to understand how Drupal works. Although - differently than Palantir - I stuck with Drupal, I agree with her/him on the fact that Drupal gets complicated complex right off the bat. This is the trade-off you have to pay in order to have a platform that - rest assured - is very flexible, extremely pluggable and rock-solid (otherwise it wouldn't have been used to redesign the whitehouse, nor Drupal would have got for the second year in a row the "best PHP CMS" award, I suppose).
The good news is: there are some excellent books out there, and I would certainly recommend "Pro Drupal Development" for an in-depth and all-around explanation of the system. Just be sure to get the 2nd edition, as the first deals with the now obsolete 5 seres. That said...
A very good thing about Drupal, at least in my opinion, is that most of the tweaks you might need to do to an existing functionality can be implemented by hooking into the original code from a custom module too. This IMO is the biggest advantage of Drupal: you never have to touch other developers' code to achieve your goals, and this means - for example - that you will be able to keep your core and contrib modules up-to-date without breaking any customisation you might have done.
Drupal is heavy. Compared to other CMS it sucks plenty of processing power and RAM from your server, and - unless you are going to have a very small site - I recommend to deploy it in conjunction with nginx, rather than Apache.
Drupal scales well, thanks to a good mechanism of caching and "throttling up" mechanisms. Strange as it might sound, Drupal scales very well on large traffic websites, so that big increases in traffic do not necessarily imply big increases in resource usage.
The user experience out-of-the-box on a Drupal site is quite poor. There is a massive work being done on this at the moment (here and here (video)), but improvements won't be available until D7 is released [soon, but then you will have to wait for the modules to be ported], so it is advisable to allocate some time to create an administrative theme, if the admins of your website won't be of the technical type.
At the end of the day, my advice is: if your site is going to go big / complex / with complicated business logic and lots of functionality, then Drupal is probably a good candidate. If your site is contrarily a small-scale one with standard functionality plus a few custom bits, maybe Wordpress / Joomla could fit your needs better [not because they are 'less powerful' but because Drupal strengths would be unused in this case, while Wordpress/Joomla simpler architecture would probably represent an advantage in this scenario]
Other options would certainly be frameworks like CakePHP or Django, for example, but that - IMO - is a totally different approach to the matter, I would say.
Short answer: Drupal is well suited to build something like that, especially if you are willing to integrate your app/logic into Drupal as a suite of custom modules. The other way, integrating Drupal into an external application, can also be done, but will give you more friction, as Drupals architecture is pretty much geared towards being a framework in its own right.
Longer answer: I have a pretty much opposite opinion/experience compared to Palantirs. I've been working almost exclusively with Drupal for a year now, in the context of two fairly complex/'enterprisy' projects (after several years of 'on the side' usage for smaller things). While I agree that it imposes some rigid rules (but not limits!), I consider this to be an advantage, as those rules give a clear guidance and provide proven ways on how to do things. The three parts Palantir mentions are good examples for this:
Menu system - Provides a well structured and effective dispatching mechanism that is easy to extend with your own stuff, while giving huge flexibility to tweak/manipulate existing/default paths. (Note that 'menu system' in Drupal denotes the whole topic of managing your URL space, not just the subset of 'visible' menus that is usually associated with the term)
Forms API - A declarative approach to web forms, with a well designed processing workflow and a whole lot of built in security features that you would otherwise have to take care of yourself. Also highly extensible, with straight options to adjust/extend already existing forms on demand, add new validation rules to any field or whole forms, multi step forms, javascript based form adjustments, etc.
Translation system - This is pretty complex, simply because internationalization is fricking hard to do. But it is built in, again giving clear guidance on how to do things in order to work in a generic way (though there are problems with quite some contributed modules that are not using/supporting it the way they should).
I could give more examples for parts where I appreciate the 'rules', but this post is getting long already, and I still have to cover some downsides ;)
So to sum up the positive part - if I where given the rough specs you posted, I'd say 'no problem' and go with Drupal, being confident that it would be a solid foundation for the custom parts, while providing all the 'standards' like forum, blogs, twitter/facebook integration and many, many others in the form of already existing solutions (even though those might need some adaption/tweaking).
Downsides: As always, there are flaws, and some of them are substantial, depending on requirements/circumstances.
Learning curve - Drupal is quite complex, and 'grokking' its concepts takes time. 'Playing with it for a week', as Palantir suggests, will certainly give you a general feeling/broad impression, but it is in no way enough to allow for a serious judgement of its pros and cons, as those will only surface while coding in/for it. So if you are already deeply familiar with an established web development framework, this might be an issue. If you have to learn one anyways, this should be less of a problem.
Database restrictions - As of Drupal 6, database support is MySQL or PostgreSQL only, using a Drupal specific 'abstraction layer' (which obviously isn't one ;)
Drupal 7 will move to PDO, which should (finally) end this questionable state.
Test/Stage/Production migrations - Parts of Drupals 'out of the box' flexibility are due to many things being configurable in the administrative backend, which implies that many important configuration settings are stored in the database. This makes migration of data and/or configuration between several instances pretty difficult/tedious, once you left the (early) stages of development where you can get away with complete dump/restore operations (see e.g. this question & answers)
These are the main ones for me, but you'll probably find more :)
I worked for over a year using drupal extensively, but I ended up abandoning it. Drupal, and other CMS systems out there, have very rigid limits and rules. I'd use Drupal for projects where you have simple requirements and few or no business rules. Drupal gets complicated almost immediately when you want to do complex things (especially pay attention at the menu system, forms, and the translation system if you need to be multilingual).
If your system will really be large, with all the things you mentioned, then I'd rather use a PHP framework to implement your business logic, and integrate external products as they fit (a forum, a blog, a twitter client, etc...).
But the advice is: don't trust anyone :) Download it, and play with it for a week. You'll be able to make your mind and be more confident about your choice!
As Drupal is open source, you can pretty much do as you wish with it. A couple of points though:
Changing Drupal's user/role structure would be tedious and unnecessary. You would need to have your desktop application authenticate from Drupal's MySQL database.
Drupal has hundreds of plugins for just about everything, so Drupal could no doubt run the whole "web" side of things including visitor stats etc. You would just need, again, to connect your desktop application to the correct MySQL tables and show the data as desired.
Don't forget to check other content management systems such as Joomla! (and many others). Each has its pros and cons. www.opensourcecms.com allows you to easily test CMSs and I've used it extensively in the past.
Just be sure to map out all the components first. Every hour planning up front saves many hours of headaches later.