[development] jQuery 1.2 is released

[William Smith]

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 at users.sourceforge.net> wrote:
>
> Quoting Larry Garfield <larry at 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070912/46a6301e/attachment.htm