Good stuff! One post from Jörn is better than a thousand from me, hehe :)
I'd say however that even the /* [relative-url] */ marker is not necessary
and just another chance for error. What you could do simply is find all
url() references and extract the necessary URL details within. It's
probab
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
Thanks Mike for clarifying. It certainly would be interesting to know
if jQuery UI could, with the 1.2.6 performance improvements, implement
the ui.mouse stuff as custom events.
Jörn
On Sun, Oct 5, 2008 at 1:34 AM, mike.helgeson <[EMAIL PROTECTED]> wrote:
>
> I always told myself I had no interes
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
On Sat, Oct 4, 2008 at 6:34 PM, mike.helgeson <[EMAIL PROTECTED]>wrote:
>
> Brandon, slightly off topic but related to drag/drop performance, Have
> you gotten a chance to look at this?
>
> http://groups.google.com/group/jquery-dev/browse_thread/thread/a4becc9a5cc34fea
> http://dev.jquery.com/ticke
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
I always told myself I had no interest in making a drag and drop
plugin, but found a repeated code pattern in my own work, and had to
explore making it re-usable. If people are happy with jQuery UI
draggable and droppable, which is great, keep using it. I have found
these drag events to be very us
Why don't we make a plugin out of this ? there's no so much of a need for
this on the core.
Then, if it seems successful, we can add it (just like offset/dimensions).
On Sat, Oct 4, 2008 at 4:26 PM, Brandon Aaron <[EMAIL PROTECTED]>wrote:
> Although it seems like we are getting further off-topic.
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
On Sat, Oct 4, 2008 at 2:03 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
>
> According to Paul, implementing everything as a normal event became
> prohibitively slow with large sets of draggables/droppables, which is why
> certain things in their draggables are implemented as callbacks (for speed).
>
I'm not sure we want to animate just the height or just the opacity in
the show('speed') / hide('speed') methods. We already have methods for
animating height (slide...) and opacity (fade...). If someone has a
suggestion for changing what show and hide do that doesn't duplicate
what other m
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
>
Although it seems like we are getting further off-topic... I often pass
around function references as strings. For example this is a common pattern
that I use.
$('div')[ test() ? 'doSomething' : 'doSomethingElse' ]();
Using something like $.callback is very explicit as to its purpose. After
all c
The code I was working on with John yesterday is at:
http://gist.github.com/14666
Note that it was very quick and dirty, and more of a port into John's stuff
than working code.
What would happen with this code is that initialize would be called, then
any addOptions, and then start. I think John ha
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
If there are conceptual reasons that this is preferred over jQuery UI's
drag/drop, it probably makes sense to see if those concepts could be added
to jQuery UI. jQuery UI's draggables are actually implemented modularly, so
you can remove a fair bit of the extra functionality and be left with some
b
The thing is that in JavaScript, all method names are just strings. For
instance:
$.fn.addClass is equivalent to $.fn["addClass"].
And you wouldn't be required to use this, but it would improve certain
situations:
$("div").slideUp("slow", $.callback("slideDown", "slow")) instead of
$("div").slid
That sounds great. I would still want a cssDir and imagesDir in the json, so
that I could simply use the last part of the relative URL marked with /*
[relative-url] */ and know where the images actually were in the package.
-- Yehuda
On Sat, Oct 4, 2008 at 2:39 AM, Jörn Zaefferer <
[EMAIL PROTECTE
Prototype's Element#fire does not support firing native events whereas
jQuery's trigger does. $.fn.trigger differs from Element#fire that it only
triggers the handlers but does not actually create and dispatch the event.
If jQuery is to use the *real* event technique, will $.fn.trigger behave
cons
The point here I was trying to make is that show/hide(time) should be
a sensible behaviour. Personally I don't think animating the width/
height is sensible, but I'm interested to hear arguments to the
contrary.
On 4 Oct, 14:59, Karl Swedberg <[EMAIL PROTECTED]> wrote:
> I'm not sure we want t
I do not like passing a jQuery method name as a string to one special
method.
A new (and a little strange) usage to jQuery.
On Oct 4, 5:06 am, "Brandon Aaron" <[EMAIL PROTECTED]> wrote:
> I'd prefer this as well.
>
> I think this also helps a few common cases of var self = $(this);
> --
> Brando
> Why should I start with a simple drag event and implement everything else
> from scratch?
I would say that it allows for total flexibility - it kind of makes
the 'drag' event work just like a normal event like 'click'.
On 4 Oct, 14:10, weepy <[EMAIL PROTECTED]> wrote:
> I used the old versi
> 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
I used the old version and found it to be very good. Very simple - it
simply provides the hooks for you to implement what you need.
I would like to know what's changed since the old version ?
On 4 Oct, 10:45, "Jörn Zaefferer" <[EMAIL PROTECTED]>
wrote:
> Could you be a bit more specific why t
To my eye, animating the width/height of an element with content looks
weird as the inner content stays the same size. Perhaps there is a
case for it but I'm not sure what it is. Animating opacity makes more
sense visually.
I've created tickets for both of these discussions outlined in this
threa
You can't really animate just the height. This would cause layouts
where an item animates in against other floated elements to break.
It's a decent animation - it's not like it's hard to create other
animations, what's the major concern here?
--John
On Sat, Oct 4, 2008 at 6:00 AM, Jörn Zaeffer
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.
Could you create a ticket for this? The discussion came up previously,
without really getting anywhere. The width/height animate should be
replaced, with whatever is more appropiate. I think Michael Geary
argued for a simple slide (animate height only).
Jörn
On Thu, Oct 2, 2008 at 8:56 PM, weepy
The usage of compare shouldn't change, I'll just try to merge compare
and compare2 into one method, and maybe into equals, if that is
possible. Currently also compare isn't recursive, so only a certain
depth is checked.
Jörn
On Thu, Oct 2, 2008 at 3:33 PM, Klaus Hartl <[EMAIL PROTECTED]> wrote:
>
Could you add your $.plugin.addOption example to the tabs example?
Would help getting an idea how those would play together.
Jörn
On Fri, Oct 3, 2008 at 8:16 AM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> Hey guys,
> At TAE, I spoke to a number of you guys about modular code, and some of you
> aske
A token that a plugin user must replace isn't acceptable, as it defies
the drop-in nature of most plugins. But there are alternatives that
would allow Yehuda to automate replacing the relative directory URL
without anyone else having to modify the file.
Something like this:
background-image: url(.
I understand what you are saying - and believe me I have much experience
with "real-projects" that have their separate image/css/javascript folders
set in a certain way. What I'm trying to impart is the idea of de-coupling
so that plugin assets are independent of whatever system it is placed into.
People who download plugins today have to go modify CSS files to make them
match their existing directory structure. I've had to contend with this more
than once with the tabs plugin, including having to figure out the issue in
the first place. Typical downloaders could use the find/replace feature
It just doesn't work that way in real life. Real projects have separate
directories with images, css, and javascript directories, that at least in
my experience, don't usually comply with the directory structure assumed by
the plugin creator.
Consider, for instance, the UI plugins. They have a them
36 matches
Mail list logo
