[development] Front page module - The way it should be.[tm]
allie at pajunas.com
Tue Jan 31 18:10:57 UTC 2006
On Jan 31, 2006, at 11:31 AM, Dries Buytaert wrote:
> Finally, someone who agrees on the fact that the enewsletter.module
> is _way_ too extreme.
I guess now's as good a time as any to point folks to my send and
news module work. In effect, it's "competing" with what enewsletter
is trying to do, but we needed the functionality so there it is.
Modularity is good, but the thing that makes Drupal strong is
modularity with vertical integration. Each module performs only one
major function, but through the hook system it can perform parts of
that function at every required stage. It's functional modularity,
not component modularity, and it's a good to meet real-world
requirements while building a foundation for later.
I've taken this approach with the cvs version of send ( http://
drupal.org/node/37480 ), which covers the functional requirement of
sending 1 or more nodes to 1 or more recipients. The first
application was to send a node to a friend, but we quickly realized
that there are many reasons and ways of doing this (petitions, guest
passes, newsletters, upcoming events, etc.), each with the same basic
functionality but slightly modified UI's and supplemental functionality.
Thanks to the Forms API, it's easy to modify send's appearance and
behavior. I've written a news module that modifies send's
composition form by replacing the recipient with a mailing list
selector. Because it's using send's functionality, you get message
logging, CiviCRM integration and additional hooks "for free". This
is accomplished in about 90 lines of code.
Other send sub-modules can take advantage of its functionality
without adding new code or overhead. And I'm working in send hooks
for modules that don't send anything, such as clickthru and open-rate
tracking, filters, message trailers, etc. that will affect every
current and future send activity. You end up with a single source of
information about which nodes got sent to whom, and for what purpose.
I also implemented a cascading variable system so that subject,
message and other settings can be set on a per-module, per-nodetype
and per-node level, with default from the next item up the tree. Not
relevant to this conversation, but interesting and probably worth a
So what I'm getting at is that modularity is good, but we shouldn't
lose sight of Drupal's strength: functional modularity through the
hook system. For efficiency and extensibility, we should seek to
develop modules that work in harmony, not just modules that can be
pajunas interactive, inc.
scalable web hosting and open source strategies
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development