|
The problem with this approach is later on when the user wants things which don't fit in with the Drupal system, modifications can be a real pain, and the site can become more and more brittle over time. Let's take another real-world example: 1. The client wants a google map of all their content
2. The client wants the content displayed elsewhere too
3. The client wants to filter the content by type
4. The client wants a tag cloud
5. The client gets what they want quickly by using drupal and is happy.
...
99. The client wants to change the google maps module to act slightly differently, but this turns out to be very difficult, and their developer takes days to make very simple changes.
100. The client is complaining that their website is slow because it loads over 200 drupal modules, but they need them all.
101. Some code is the db, and some on disk, which makes it very difficult to trace execution.
102. The client can no longer update their drupal as half of their modules are no longer maintained, and they're at the mercy of the module developers to do so, this causes problems using new modules which expect a newer drupal.
103. New developers can't get up to speed because the code-base is so convoluted and the database contains over 200 tables with a byzantine structure caused by drupal's over-abstraction of content types - the client runs through a series of several drupal developers and bleeds money with no significant changes to their site and lots of bugs left unfixed.
...
200. The client gives up and starts again with a site rewrite using another framework, and curses the day they were introduced to drupal. The up-front development cost may sometimes be lower with drupal (though for many sites I would dispute that, most frameworks make it a matter of minutes or at most hours work to add a tag cloud for example, or add a map, with the advantage that you don't have to use a module to do it), but unless you are very careful and stick with one developer, the huge technical debt you're taking on by using it doesn't justify that. The fact that the developers ever thought it was a good idea to store code and views in the db is a huge red flag, and is a huge temptation to some developers and/or clients to produce a huge complicated, unmaintainable mess. Even if you try to control this it doesn't ledn itself easily to separation of concerns. I'm sure it's quite possible to produce clean websites with drupal and keep them under control long term, but it's not the pattern of the sites I've seen, and I don't think it really gives you so much more in the longer term over developing in simpler frameworks which don't try to prescribe as closely how the content is structured. |