Actually that argument doesn't follow.  Many modules, (e.g. views) provide blocks, but do not require them in order to function.  If your module is one of those it doesn't make sense  to indicate blocks as a dependency.  I haven't researched it but I do believe that most block providing modules fall into that category.   Dependencies should be reserved for such cases when your module simply will not function without the other module.  I think you could still make that argument for modules that exist to only provide a filter, but it shouldn't be viewed as documentation for what features a module provides. \\Dave


On Oct 4, 2008, at 8:50 AM, Nancy Wichmann wrote:

<image001.jpg>

When I did this in one of my filters, I looked to see how it documents and discovered my own answer.  This could get absurd because then we should have everyone who supplies a block list the block module, and etc.

 

So never mind.

 

Nancy E. Wichmann, PMP

 

 

-----Original Message-----
From: development-bounces@drupal.org [mailto:development-bounces@drupal.org]On Behalf Of Nancy Wichmann
Sent: Saturday, October 04, 2008 11:30 AM
To: Development@Drupal. Org
Subject: [development] Filter-sophical question

 

Since Filter is a core-required module, we do not need to list it as a dependency in filter modules.  Technically, this is wrong (not listing a dependency).  I have not seen any filter module that actually lists filter as a requirement.  While it does not cause any serious problems, it does result in incomplete self-documentation.  Should we encourage filter module owners (including me) to correct this?

 

Nancy E. Wichmann, PMP

 

 

<image001.jpg>
This message cannot be displayed because of the way it is formatted. Ask the sender to send it again using a different format or email program.

multipart/alternative
No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.7.5/1704 - Release Date: 10/2/2008 9:35 PM