I think that is where the misunderstanding is coming in. We need to decouple those terms in this case .. module being a Drupal module, plugin being a jQuery plugin.
http://jquery.com/plugins/
currently lists 363 available jQuery plugins. What Larry seems to be talking about is having 1 single Drupal module to activate/deactive this plugins if they are available on the local system, rather than having 363 individual Drupal modules to active/deactive these plugins.
It seems like a reasonable approach to me. Conflating module and plugin in this case is what is leading to the confusion, I think.
William
On 9/12/07,
Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Larry Garfield <larry@garfieldtech.com>:
>
>> Excuse my ignorance but why wouldn't the module system we already have
>> suffice? The .info file would allow for the enable/disable and each
>> .module would add the enabled JS to the queue.
>
> Because then you'd need a separate Drupal module, with some
> boilerplate PHP, for every JS plugin you want to install. I'm
> talking about a small framework module that lets you manage what 3rd
> party JS plugins are installed. The same PHP code in a half-dozen
> different modules is a very bad thing. :-) (insert usual commentary
> about duplicate code here)
>
The .info file will handle the administration of de/activating the JS
plugin module. Sometimes using the same code is necessary but that is
what my question was trying to prevent. I don't see why you want
another method to control activation of the module (I envision plugin
and module as synonyms).
Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/