<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Jan 31, 2006, at 11:31 AM, Dries Buytaert wrote:</DIV><BLOCKQUOTE type="cite"></BLOCKQUOTE><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Finally, someone who agrees on the fact that the enewsletter.module is _way_ too extreme.</DIV></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I've taken this approach with the cvs version of send ( <A href="http://drupal.org/node/37480">http://drupal.org/node/37480</A> ), 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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><BR><DIV> <DIV>Allie Micka</DIV><DIV>pajunas interactive, inc.</DIV><DIV><A href="http://www.pajunas.com">http://www.pajunas.com</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>scalable web hosting and open source strategies</DIV><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Courier New" size="3" style="font: 12.0px Courier New"></FONT></P> </DIV><BR></BODY></HTML>