Brandon, thats really the approach that Scott and I promoted for a
long time, though maybe the focus on jQuery UI didn't help making that
clear. There never was the intentation to rush this into core,
especially considering that we will hardly be able to change the API
after releasing it as part of core. There just aren't that many major
releases.
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() {});
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.
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'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.
Jörn
On Sun, Oct 5, 2008 at 1:12 AM, Brandon Aaron <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
