In a way it feels like we are trying to build just another class helper instead of just using prototypes. I understand we want to make it easy to build extendable and modular plugins/widgets. I think I see how the plugin builder can help us do that but I think it would be wise to get it working within jQuery UI first. Lets make some extendable and modular widgets within jQuery UI using the plugin/widget builder/factory and then make it more readily available when we've proven it meets our goals.
-- Brandon Aaron On Sat, Oct 4, 2008 at 5:12 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote: > Brandon, > I agree that this is not a generic plugin builder. However, its use-cases > go further than just jQuery UI. It's useful for: > > * any plugin that needs to encapsulate state > * any plugin that wants to be extended by other plugins > > Adding it to jQuery UI means that people who want to build simple > extensible plugins need to think about adding a part of jQuery UI as a > dependency for their plugin. As this is only 50 or so lines, I see a lot of > value in adding it to -core, but making clear that it's only to be used if > you mean to be writing something stateful or extensible. > > -- Yehuda > > > On Sat, Oct 4, 2008 at 3:01 PM, Brandon Aaron <[EMAIL PROTECTED]>wrote: > >> Okay ... so I've been playing around with this for a little while and have >> a few thoughts. >> >> First, it raises the barrier to entry on writing plugins... even if it is >> small, it is one more thing to know and understand. >> >> Second, I've written a lot of plugins that certainly do not fit into this >> structure very well. For example, I don't believe any of the methods found >> within Dimensions would have benefited from this plugin builder. Live Query >> is another example of a plugin that just doesn't fit into the mold for this. >> Furthermore, I use $.fn to encapsulate chunks of functionality to make my >> code more readable and maintainable. Using the plugin builder for these adds >> unneeded complication. >> >> Third, the bgiframe plugin seemed to convert into this format the easiest >> but I don't believe anything was gained by using the plugin builder vs just >> $.fn. Only the overhead of the plugin builder itself. >> >> I'd like to hear anyone else's experience in converting their existing >> plugins ... especially from Ariel and Joern. Right now I'm still believe >> that this is best kept within jQuery UI and branded as a widget builder. >> >> -- >> Brandon Aaron >> >> >> On Fri, Oct 3, 2008 at 9:27 AM, John Resig <[EMAIL PROTECTED]> wrote: >> >>> Hi Guys - >>> >>> At the Ajax Experience we talked about possibly making a reusable >>> function for helping to encapsulate much of the functionality commonly seen >>> in jQuery plugins. >>> >>> The important points seemed to be: >>> - Plugins need a way to maintain state from one call to the next >>> (generally in the form of 'options'). >>> - The state needs to be directly associated with the elements that >>> they're called on >>> - There needs to be a default set of options to load state from >>> - Plugins need to clean-up any events or data that they bind to an >>> element >>> - All methods introduced by a plugin should have access to the same >>> state >>> >>> I put my code up here: >>> http://dev.jquery.com/~john/plugins/widget/ >>> http://dev.jquery.com/~john/plugins/widget/widget.js >>> >>> This is how you would use it: >>> >>> The most basic call: Adds a single method (.test()) whose 'this' >>> represents an individual element wrapped in a jQuery set. An empty options >>> object is provided, as well. >>> >>> jQuery.plugin("test", function(a, b){ >>> this.options = a; >>> this.hide(b); >>> }); >>> >>> jQuery("div").test("woo", "slow"); >>> >>> Equivalent to the first style shown above. >>> >>> jQuery.plugin("test", { >>> setup: function(a, b){ >>> this.options = a; >>> this.hide(b); >>> } >>> }); >>> >>> jQuery("div").test("woo", "slow"); >>> >>> Next step up: A default set of options is provided - which implies that >>> the first argument to .test() will be an options object. >>> >>> jQuery.plugin("test", { >>> options: { speed: "slow" }, >>> setup: function(){ >>> this.hide( this.options.speed ); >>> } >>> }); >>> >>> jQuery("div").test({ speed: "fast" }); >>> >>> >>> >>> Add in some related methods (related to the root setup method) that also >>> have access to the instance and options. >>> >>> jQuery.plugin("test", { >>> options: { speed: "slow" }, >>> setup: function(){ >>> >>> >>> >>> >>> this.hide( this.options.speed ); >>> }, >>> methods: { >>> test2: function(){ >>> this.show( this.options.speed ); >>> } >>> } >>> }); >>> >>> jQuery("div").test({ speed: "fast" }).test2(); >>> >>> >>> >>> Remove some functionality added previously: >>> >>> jQuery.plugin("test", { >>> options: { name: "test" }, >>> setup: function(){ >>> this.addClass( this.options.name ); >>> >>> >>> >>> >>> }, >>> teardown: function(){ >>> this.removeClass( this.options.name ); >>> } >>> }); >>> >>> jQuery("div").test({ name: "blah" }); >>> >>> and the cleanup is triggered by (where 'test' is the name of the plugin >>> that you wish to remove): >>> >>> jQuery("div").trigger("remove.test"); >>> >>> It's not completely clear yet what will happen with the above plugin - I >>> just wanted to put it out there since there was some interest in seeing it. >>> >>> --John >>> >>> >>> >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
