[drupal-devel] Re: [contributions:MegaGrunt] /modules/publication publication.module publication.mysql readme.txt

Robert Castelo services at cortexttranslation.com
Sun Sep 11 23:03:36 UTC 2005

First off, apologies for taking so long to reply, I've been on holiday 
for a few weeks.

Hope this answers your questions:

On 19 Aug 2005, at 02:04, drupal-cvs at drupal.org wrote:

> User: MegaGrunt    Branch: HEAD    Date: Fri, 19 Aug 2005 00:04:08 
> +0000
> Added files:
>   /modules/publication publication.module publication.mysql readme.txt
> Log message:
>   Handles data, logic, and UI of publication(s).
>   Component module which provides service to other modules.

On 19 Aug 2005, at 07:45, Dries Buytaert wrote:
> - This does mean what?  I guess I'll have to read the readme.txt

I wanted to explain two things with this log message...

1) This is a 'component' module.

A module which manages a certain task/service on behalf of other 
modules. It has no dependencies on any other modules, and can be called 
by any module that needs this particular service.

Other examples of component modules in contrib: Actions, Forms, and 

2) Purpose of publication.module

Manages the content of a publication(s).

Content is defined as a collection of terms, which can come from one or 
more categories. In future I'd like to expand the module to handle 
other ways of aggregating content, e.g. node specific selections.

A publication can be any collection of content, for any purpose, e.g. 
web site section, email newsletter, PDF, RSS, screen reader -> VOIP, 

See the project page:

> (which should be README.txt really).

OK, I'll change that on all my commits.

> - I'm afraid the subtle differences in your modules' names are 
> somewhat confusing:

Purpose of the other component modules I committed:

* Schedule module - manages schedules, i.e. various time settings.
See the project page:

* subscribed module - ties users to publications/actions/whatever
See the project page:

* templates module
Stores templates in the database, which are used by other modules, e.g. 
email templates, PDF templates, etc.
Templates can be edited through the browser, and can use profile and 
site data.
See the project page:

>    + There is already a scheduleR module.  How does your schedule 
> module differ?

ScheduleR module publishes/unpublishes nodes at scheduled times.

Schedule module allows any other module (including ScheduleR) to manage 
schedules for any purpose, e.g. auto publishing a PDF, deleting nodes 
from a demo site, sending email, publishing/unpublishing nodes.

In other words, ScheduleR is single purpose, Schedule is generic enough 
to be leveraged by any other module.

>    + There is already a subscription module.  How does your subscribe 
> module differ?

There are actually 4 subscription related modules in contrib cvs, plus 
others like notify.module with similar functionality.

This is why I'm so keen on component modules - most of the 
functionality of these modules is the same, the common tasks could be 
handled by 1 subscription component, leaving developers to concentrate 
on the unique features of their module.

Current situation is that each of the developers of these modules is 
spending time creating and maintaining much the same set of 
functionality as the others.

> Doesn't JonBob have a subscribe module too?

Yes, I talked to JonBob about merging the two modules. While we both 
like the idea, our projects where too much of a moving target to 
attempt to do this. Once we get a stable release of both modules I'd be 
interested in merging the two.

> (I want a subscription.module in core (e-mail notifications) but don't 
> want to ship both a subscribe and subscription module.  I want a 
> single-file module with or without additional .inc files.)

If I understand correctly, you want users to be able to subscribe to 
scheduled email notification of new content (nodes and comments).

The component modules I committed perform most of the necessary tasks 
for this already, but not comment subscription (yet!).

> - What other modules are going to re-use the scheduler and subscribe 
> modules?

The eNewsletter module and Announcement module use the component 
modules I committed.


Plus others in the pipeline....

> - The e-commerce module groups its modules in modules/ecommerce.  In 
> general I like that better, because it makes for one well-defined 
> project.

If they were for use only by enewsletter module, it would indeed make 
sense to collect them in modules/ecommerce - but as the whole point is 
to use them for  a wide variety of other modules, and each component 
module is independent of the others, it made more sense to give each 
one their own directory.

What would be better of course would be to create a separate cvs 
directory for components ;-)

Best regards,

Robert Castelo [MegaGrunt]

More information about the drupal-devel mailing list