[development] jQuery 1.2 is released

Larry Garfield larry at garfieldtech.com
Wed Sep 12 21:17:58 UTC 2007

Yes, what William said. :-)  A single Drupal module to act as a controller / central repository for jQuery plugins, so that we don't have a dozen Drupal modules with the 20 lines of PHP (or whatever) needed to bootstrap the module just to call drupal_add_js().  Better to have one Drupal module that is 30 lines (plus another 100 of page handling code in a page-split file <g>) and can handle all of them.

The question is whether that loading should be admin-controlled or instigated by modules implementing a hook.  (E.g., a _jquery() hook from which modules return the name of jquery plugins they need, and this central module then loads just those.)  I guess this is something we should be talking to John Resig about, too. :-)

--Larry Garfield

On Wed, 12 Sep 2007 15:28:44 -0400, "William Smith" <william.darren at gmail.com> wrote:
> 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/

More information about the development mailing list