[development] D7 contrib module development
Matt at NinjitsuWeb.com
Sun Mar 8 22:20:07 UTC 2009
Marcel Partap wrote:
>> If you really want to help improve contrib, then help by writing
>> more "comparisons of duplicated modules"
>> (http://drupal.org/node/266179 - though the handbook is a bit
>> messed up since the upgrade).
> Waste of time better spent on reimplementing functionality in the best
> possible manner.
There lies the fallacy. I don't believe there is any 'one best solution'
for most given problems, especially in Drupal.
Which is better: a simple solution that gives a few features out of the
box, or a highly configurable, extensible solution that requires
multiple configurations before it can be used? It depends on the site
being built and on the site builder. In the realm of email subscription
modules, for example, the needs of an internal documentation site versus
a public news publishing site are very different.
Likewise, Site builders who are coders are going to be drawn to the
module that describes itself this way:
"This is a complete Subscriptions/Notifications Framework aiming at
extendability and escalability. It allows any number of plug-ins
defining new event types or subscription types or a different user
Site builders who are afraid of PHP will drawn to:
"This module allows users to subscribe to periodic emails which include
all new or revised content and/or comments much like the daily news
letters sent by some websites"
or, if they already know the drupal lingo and need more power, maybe:
"This module enables users to subscribe to be notified of changes to
nodes or taxonomies, such as new comments in specific forums, or
additions to some category of blog."
Duplicated modules aren't necessarily competing modules. I think it's
good to have different modules focused on meeting the needs of different
audiences. One size does not fit all.
It was suggested that some duplicated modules exist solely to feed
developer ego. That's not the most flattering way to put it, but I have
noticed that being the maintainer of a module does lead to business
inquiries; I'm not keen to give up the publicity. One possible solution
to this would be to have project pages list all the committers for a
project, and not just the one owner. This would increase the value of
collaboration and decrease the hesitation for developers to let a module
die in favor or a new, truly better solution.
More information about the development