[development] Front page module - The way it should be.[tm]

[Allie Micka]

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  
look.

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  
cobbled together.

Allie Micka
pajunas interactive, inc.
http://www.pajunas.com

scalable web hosting and open source strategies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060131/e75c68db/attachment.htm