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
-~----------~----~----~----~------~----~------~--~---
