I agree with both Yehuda and Brandon. It would be useful to a certain
portion of plugin developers (it just so happens that there's a large
overlap in the realm of jQuery UI). But the potential confusion that
could be introduced would not serve us well.
I'd like to propose something: We let the API stabilize (let Joern and
the UI team mess around with it and take feedback) and then integrate
it into UI core (replacing $.widget). We then make a standalone copy
of $.plugin (jquery.plugin.js?) for plugin authors to try. If enough
plugins work with it and make it a dependency then we can bring it in
to jQuery core (same as any other addition).
It's pretty obvious that there's still a large swath of plugins that
would not immediately benefit from $.plugin so we should be prudent
when making an introduction of this sort.
--John
On Sat, Oct 4, 2008 at 11:37 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> Something like $.plugin is actually a little bit orthogonal from whether to
> use a class builder or prototypal inheritance, because it's not really
> designed to be a class system. It's designed, instead, to store various bags
> of properties, defaults, and functions in a standard way. The tabs code that
> I posted to the list ported almost directly to $.plugin.
> My only concern with having it in UI is that I doubt it'd be available as
> plugin.ui.js. It'd probably be a part of core.ui.js, which just means an
> additional dependency, which means that chance of it getting enough adoption
> to justify putting it in the core is small. A catch-22 of sorts.
> -- Yehuda
>
> On Sat, Oct 4, 2008 at 6:29 PM, Brandon Aaron <[EMAIL PROTECTED]>
> wrote:
>>
>> On Sat, Oct 4, 2008 at 7:38 PM, Jörn Zaefferer
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> About your subjection to $.plugin for the plugin you mentioned.
>>> Comparing these two looks like very little overhead when writing a
>>> plugin one or the other way:
>>>
>>> $.fn.myPlugin = function() {});
>>> $.plugin("myPlugin", function() {});
>>
>> The syntax isn't that different at a glance but of course using the
>> $.plugin builder/factory is going to have more overhead.
>> Here is a trimmed down example from the TiVo JS
>> ( http://www.tivo.com/assets/js/application.js ):
>>
>> jQuery.fn.extend({
>> scalable_bg: function(options) { ... },
>> make_buttons: function() { ... },
>> make_dividers: function() { ... },
>> add_corners: function() { ... },
>> make_faqs: function() { ... },
>> make_tabs: function() { ... },
>> make_tooltips: function() { ... },
>> make_popups: function() { ... },
>> check_images_enabled: function() { ... }
>> ...
>> });
>> That gets a whole lot uglier with $.plugin repeated... perhaps we could
>> create a $.plugins but still not the same.
>>
>>>
>>> On the other hand, the latter would give a teardown method that cleans
>>> up custom data and events, without having to implement anything
>>> related to that. It also handles options, gives you an instance to
>>> store internal state and maybe a plugin-mechanism to add further
>>> extensions to your plugin, what Yehuda is promoting.
>>
>> I agree that when porting the bgiframe plugin to this $.plugin builder it
>> got a standard way to then trigger a destroy. It was completely possible
>> before and documented but standards are nice. Just not sure that single
>> benefit was enough for me to use $.plugin for bgiframe.
>>
>>>
>>> What I like about $.plugin is the ability to just make it part of the
>>> API documentation - so far the writing-plugins documentation really
>>> isn't that great, and you always have to explain what $.fn actually
>>> is.
>>
>> I believe you will have to write (and answer) much more about $.plugin
>> than you would with $.fn. Your going to have to explain the main two ways to
>> use $.plugin. Then your going to have to explain what setup and teardown
>> mean, then what methods means, then what instance means... and so on. Your
>> still going to have to explain what 'this' is and all that normal stuff.
>>
>>>
>>> I'm going to port a few plugins in the next days to $.plugin and try
>>> to make it work with jQuery UI. I hope to provide better usecases
>>> based on that.
>>
>> I can't wait to hear your thoughts on using $.plugin for your validation
>> plugin and any others!
>> --
>> Brandon Aaron
>>
>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
