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
wit
As long as we could make this a standalone dependency without the
entanglement of convincing new users to use "jQuery UI" as a dependency, I'd
be cool with it.
-- Yehuda
On Sun, Oct 5, 2008 at 6:15 AM, John Resig <[EMAIL PROTECTED]> wrote:
>
> I agree with both Yehuda and Brandon. It would be use
About the confusion/explaining thing: $.plugin would provide a
documented API for creating non-trivial plugins. With a few examples,
people would be able to use it without having to understand all the
underlying abstractions. Eventually they need to learn them anyway,
but so far basically everyone
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 A
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 tha
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
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
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
struct
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 simpl
The important thing is that there be an idiomatic way to call those methods.
I'm perfectly cool with having an instance property bag that serves to
encapsulate instance state and methods. That way, this.foo would work as
expected pretty much across the board. Also, options wouldn't get
overloaded.
> It's not perfectly clear to me what the correct idiom for adding
> widget-specific functions (i.e. methods not intended to be exposed, but
> intended to encapsulate state) to $.plugin would be. One option would be to
> store them on the options object, but that seems a bit kludgy. Did you have
>
It's not perfectly clear to me what the correct idiom for adding
widget-specific functions (i.e. methods not intended to be exposed, but
intended to encapsulate state) to $.plugin would be. One option would be to
store them on the options object, but that seems a bit kludgy. Did you have
something
> The main difference I see between how this works and how the UI widget
> factory works is that this exposes multiple functions in $.fn. When
> the UI widget factory was first written all it did was handle
> encapsulating all methods into one $.fn method to prevent polluting
> jQuery's method na
The main difference I see between how this works and how the UI widget
factory works is that this exposes multiple functions in $.fn. When
the UI widget factory was first written all it did was handle
encapsulating all methods into one $.fn method to prevent polluting
jQuery's method namespace.
Adding the functionality I want is just a few LOC:
http://gist.github.com/14660
line 99 adds the addOption method, and line 60 adds the loop to trigger the
new options at setup time.
-- Yehuda
On Fri, Oct 3, 2008 at 2:41 PM, John Resig <[EMAIL PROTECTED]> wrote:
>
> I just uploaded a new copy o
I just uploaded a new copy of the code that handles getData/setData
seamlessly. Additionally I also add .option(pluginname, key, value)
which is equivalent to .data("key.pluginname", value).
Clocks in at about 51 lines of code.
--John
On Fri, Oct 3, 2008 at 4:49 PM, Yehuda Katz <[EMAIL PROTEC
A requirement not encapsulated in the set of requirements you mentioned
above is:
* It should be possible to add new options to existing plugins to make
modifications based on the existing options/events in the plugin.
The way I was suggesting doing it was similar to what I did in the tabs post
I
I like it. It's positive to keep working with names like setup and
teardown (from events).
--
Ariel Flesler
http://flesler.blogspot.com
On Oct 3, 11:27 am, "John Resig" <[EMAIL PROTECTED]> wrote:
> Hi Guys -
>
> At the Ajax Experience we talked about possibly making a reusable function
> for hel
I'm going to try this out by adpating various existing plugins to use
it. So far its a very good step in the right direction: Providing an
abstraction to write plugins that can be just as simple as adding to
$.fn, but with a clean API and the ability to use options, keep
internal state and automati
19 matches
Mail list logo
