http://www.devnetwork.com/devnetwork-ecosystem/
http://www.devnetwork.com/wp-content/uploads/2014/05/Landscape-forweb.png
Tuesday, May 13, 2014
Wednesday, April 2, 2014
Drupal development and use by professional programmers .. are there specific pitfalls or advantages?
The following was originally posted to StackOverflow in 2009.
(http://stackoverflow.com/questions/1715811)
The post was unfortunately deleted by some StackOverflow users.
It is reproduced here for historical purposes. It was the earliest (apparently the first) public proposal to advocate the use of YAML in Drupal, as a basis for enhancing the professionalism, maintainability, and flexibility of the product. After some resistance by the Drupal community, YAML was recognized and adopted for use in Drupal version 8.
Background: Long ago Microsoft Access gained a lot of popularity because you could build pretty powerful desktop database applications with point-and-click ease. It seems like Drupal is now doing the same thing, except for the web.
This is definitely good in some aspects, but it seems to have some drawbacks as well. From the perspective of someone with a few years of Web development experience and programming experience, it seems like Drupal has some quirks that take some getting used to.
Examples:
- OOP and Namespaces: Drupal pretty much re-invents Object Oriented programming with its own internal API, and there does not seem to be much impetus to change that, even though PHP has added built-in support for (its own flavor of) OOP. See Drupal on OOP.
- It works for me ...: Many contrib modules seem to be plagued by use cases that were not initially anticipated by the original author(s). The common response is "well, at least it works for me". This is understandable when developers write something first to solve their own particular issues, and then only later adapt it for others (if funding, personal preferences, and time allow). The problem is "good enough for me" is an incremental approach that does not work well with large-scale development. The result is a combination of solutions that feel "duct taped" together.
- Duplicated Standards: Drupal seems to also re-invent existing technologies and standards even in cases where there does not seem to be a stylistic or strategic benefit in doing so. For example: 1) New .info files; 2) Deployment tools; 3) Re-creation of PHP language features; 4) Re-creation of code and functionality from established open-source libraries.
(The newly-invented .info files (used in configs), are used instead of already built-in INI file format of PHP, or the already-used and published JSON or YAML, for cases where INI is not powerful enough. Another example, in contrib modules at least, you can find lots of hand-made regexes used to parse HTML, instead of already-developed full-fledged HTML parsers. Another example, Drush appears instead of any already-known build language out there (EDIT: the build language link is not a good one, I meant to emphasize higher-level tools like Rake, Capistrano, Ant, Maven and others, I am assuming Drush is the closest thing.))
- Unit testing: Drupal does not seem to have a strong support for unit testing. Combined with the other factors above, this makes for a challenging environment for those who want to have comprehensive code coverage, especially for cases where Drupal is being used in a work environment with the potential for lots of apps proliferating.
Question: If you have some Drupal experience, and also some programming experience (especially if it is in other languages in addition to PHP, with native support for OOP), what are some specific pitfalls or even advantages that you have encountered?
- Update: (Jul 2, 2013) Drupal 8 is slated to use YAML instead of the Drupal-specific .info file format (http://en.wikipedia.org/wiki/YAML)
- Update: (Jul 3, 2013) Drupal 8 is slated to use the SYMFONY framework which includes native support for Namespaces and Object Orientation.
what were the examples of duplicate standards? – Jeremy French Nov 11 '09 at 15:36
| |||||
added, sorry for the omission – dreftymac Nov 11 '09 at 15:59
| |||||
thanks a lot for the feedback ... regarding "build language" the reference includes higher-level tools as well, not just those for compiling to binaries. (See e.g., tools like rake, capistrano, Ant) – dreftymac Nov 11 '09 at 18:27
| |||||
modxcms.com/forums/index.php/topic,15522.0.html Here is a link to a review from someone who asserts 25 years of software development experience. – dreftymac Mar 25 '10 at 19:43
| |||||
see also: mikebernat.com/blog/The_Problem_with_Wordpress_and_Drupal – dreftymac Jan 19 '12 at 22:24
|
closed on StackOverflow♦ Apr 8 '13 at 7:02
deleted from StackOverflow Feb 27 at 22:05
OOP: Drupal well predates the prominence of PHP 5, when OOP in PHP really became up to par. In fact, the upcoming Drupal 7 will be the first release of Drupal which requires at least PHP 5.2. So there is a bit of a legacy in the API which sidesteps the OOP issue. On the other hand, newer structures such as the new database API which will be introduced in D7 and the automated testing system use PHP 5's OOP features quite extensively. It's possible that this OOPness will spread to the older parts of core, but it certainly ain't gonna happen overnight.
If you're coming from languages with historically stronger OOP support like Ruby, or from post-PHP 5 PHP frameworks with more ingrained OOP support like CakePHP or Firestarter, I can see how the relative dearth of OOP in Drupal can be shocking and disturbing. On the other hand, I think Drupal is engineered well enough that it doesn't really suffer for lack of it, once you wrap your head around things.
Duplicated standards: I agree with you there - once it became apparent that standard INI files would not do all that we needed them to, we should have switched to another, well-established standard (preferably one that had another built-in, low-level parser in PHP - so not YAML) instead of adding our own extensions to the INI "standard." But for what it's worth, PHP 5.3's built-in INI parsing feature upgrades will make much of Drupal's INI parsing features redundant.
Unit testing: Drupal 7 incorporates a rather thorough testing system in core, and many of those features are available as contributed (non-core) modules in D6. I've heard pedantic people say that it's not truly unit testing and is instead process testing or something like that, but the fact remains that it's an automated testing system, and the drastic improvement in quality it has afforded the Drupal project as well as contributed modules is already clearly apparent.
As for Drush, as others have mentioned, it's not like a build system at all - it's a script which allows us to do some common Drupal tasks, such as enabling modules or forcing a cron task run, through the command line instead of the web browser.
| |||||||||||||||||||||||||||
|
IMHO, Drupal is heading down the same road as things like ZOPE or PLONE in the Python world, or SAP in the enterprise world. It is becoming a little world unto itself and a professional programmer risks being sucked in until they are only seen as a Drupal person, not a general purpose developer.
Some people may like that and certainly in the SAP and ZOPE worlds, people make a career out of working with that one tool.
| |||
| comments disabled on deleted / locked posts |
In answer to your question. As an OOP programmer coming to Drupal, don't mistake Drupal for OOP it is different, and the areas which seem familiar probably don't work in the way you expect from an OOP background.
For example, you could think of modules as an instance of an abstract module class, which can implement various methods. But they are not, and thinking they might be will confuse the heck out of you.
It comes down to a question of focus. OOP is designed to solve the problem domain of everything which means that it has to be flexible enough to do just about anything.
Drupal is designed to be a content management framework. This gives it a much tighter focus, so the design decisions are based around that.
| |||||||||||||||
|
A/B splittesting: none
IMHO the set drupal core modules is too small, so the frequent bugfix updates breaks trivial things like url rewrite, meta description and lightbox, since these things are outside the core. Causing much trouble.
| |||||||||||||
|
I think it's a bad example to compare drush with build language, from your wiki link:
This is not what drush can do or is used for. It's a simple util tool to preform things that developers do a lot like downloading a module, enabling/disabling it, running sql on your drupal db and other nice things. Like they state themselves:
But even with this poor example, it's true that Drupal reinvents a lot of things instead of using other known solutions out there.
One of the things that you have to get down, when developing with drupal is the naming convention. Drupal doesn't use namespacing but instead a special naming convention. This is something that probably wont change anytime soon. The problem with this is, that until you know how this conveention work, misnaming functions can be a cause to a lot of wondering and confusion as to why this isn't working as expected.
Drupal uses hooks, this is a part of the special drupal naming convention. The way drupal think, it not to subclass things to make what you want, but instead have one version, that any one at anytime can change and tweak to their bidding. This can sometime cause some funny errors if both module A and modeule B wants to make changes in the same flow of code. There are also different levels of overiding, some taking precedence over others, and some being performed later that others. In most cases this works just great, but around central modules like node, cck, views and others, this can become a minefield, where you have to take care if you want to change things without messing things up along the way.
| |||||||
|
Subscribe to:
Posts (Atom)