Re: [jQuery] jQuery 1.1 API improvements (macros, events)
Andrea Ercolino schrieb: dave.methvin wrote: Then there is the classic ambiguity of .unload(). Does it call an onunload handler, or does it unbind all onload handlers? There is no doubt with .un(load) or .on(unload, fn) which are only a few characters longer. OK. But I don't think that on and un are better names than bind and unbind, the former are shorter but the latter mean exactly what they say, no explication necessary. I totally agree with that. I'd also like too see bind and unbind as replacement for click etc. in 1.1... -- Klaus ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
[jQuery] jQuery 1.1 API improvements (macros, events)
Hi folks,
the discussion so far led to the conclusion to remove all those macros
for css() and attr(), eg. color() or val(). css() and attr() are already
quite flexible: Both allow you to get a single property, set a single
property or set a set of properties. I wonder if it would help to extend
them to allow getting of multiple properties at once. A possible
implementation would accept an array of String and returns a key/value
object, with the values of the array as the keys. Is this useful?
Another interesting point that needs some discussion:
The event system is improved by accepting:
- an amount paramter (the number of times to execute an event handler,
default is infinite) and additional data when binding events
- an bubble paramter (to trigger handlers of parent elements) and
additional data when triggering events programmatically
The big so far unsolved question: What should the API methods look like?
How to pass the additional data to the event handler?
Currently I favor an interface that looks like this:
$().bind(type of event, eventHandler, {amount: 5, data: additionalStuff})
$().trigger(type of event, {bubble: true, data: moreStuff});
This avoids any type checking of arguments and provides a clear API: A
little bit more to type, yet less confusion when you need only one of
the optional paramters.
Possible interfaces for the event handlers:
$().bind(click, function(event, bindData, triggerData) { ... });
$().bind(click, function(event) {
event.bind // contains bind data
event.trigger // contains trigger data
});
Your opinions?
--
Jörn Zaefferer
http://bassistance.de
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
On 27/11/06, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Hi folks,
the discussion so far led to the conclusion to remove all those macros
for css() and attr(), eg. color() or val(). css() and attr() are already
quite flexible: Both allow you to get a single property, set a single
property or set a set of properties. I wonder if it would help to extend
them to allow getting of multiple properties at once. A possible
implementation would accept an array of String and returns a key/value
object, with the values of the array as the keys. Is this useful?
Another interesting point that needs some discussion:
The event system is improved by accepting:
- an amount paramter (the number of times to execute an event handler,
default is infinite) and additional data when binding events
- an bubble paramter (to trigger handlers of parent elements) and
additional data when triggering events programmatically
The big so far unsolved question: What should the API methods look like?
How to pass the additional data to the event handler?
Currently I favor an interface that looks like this:
$().bind(type of event, eventHandler, {amount: 5, data: additionalStuff})
$().trigger(type of event, {bubble: true, data: moreStuff});
This avoids any type checking of arguments and provides a clear API: A
little bit more to type, yet less confusion when you need only one of
the optional paramters.
Possible interfaces for the event handlers:
$().bind(click, function(event, bindData, triggerData) { ... });
$().bind(click, function(event) {
event.bind // contains bind data
event.trigger // contains trigger data
});
Your opinions?
--
Jörn Zaefferer
http://bassistance.de
The problem with removing all the helper methods is that some are very
heavily used (especially val and click). While that may reduce
jQuery's file size, it will increase the size of many plugins and
pages that use jQuery.
Moving out of core may be a good idea if file size really is that
important (many have broadband or fast dialup and you can always use
gzip compression on the server), but it would still be good if these
(or at least the most used ones) were still part of the default
download (i.e. http://jquery.com/src/jquery-latest.js).
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
Sam Collett schrieb: The problem with removing all the helper methods is that some are very heavily used (especially val and click). While that may reduce jQuery's file size, it will increase the size of many plugins and pages that use jQuery. The basic problem: The API cluttering. There are 2 methods for each attr macro and 2 methods for each css macro. They can all be handled by using attr and css directly. On the other side, it is easy to add them back when really needed, or provided as a compability plugin. Moving out of core may be a good idea if file size really is that important (many have broadband or fast dialup and you can always use gzip compression on the server), but it would still be good if these (or at least the most used ones) were still part of the default download (i.e. http://jquery.com/src/jquery-latest.js). This isn't so much about file size, more about a clean API. Currently the core has simply to many methods that do pretty much the same. -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
On 11/27/06, Sam Collett [EMAIL PROTECTED] wrote: The problem with removing all the helper methods is that some are very heavily used (especially val and click). While that may reduce jQuery's file size, it will increase the size of many plugins and pages that use jQuery. In addition to what Jörn said about cleaning up the API, it is about reducing confusion about what .click() and other event methods actually do or don't do. -- Brandon Aaron ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
On 11/27/06, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Currently I favor an interface that looks like this:
$().bind(type of event, eventHandler, {amount: 5, data: additionalStuff})
$().trigger(type of event, {bubble: true, data: moreStuff});
This avoids any type checking of arguments and provides a clear API: A
little bit more to type, yet less confusion when you need only one of
the optional paramters.
Possible interfaces for the event handlers:
$().bind(click, function(event, bindData, triggerData) { ... });
$().bind(click, function(event) {
event.bind // contains bind data
event.trigger // contains trigger data
});
Your opinions?
I think I prefer the suggestion made by Dave Methvin of using on() and
un() instead of bind.
$().on('click')
$().un('click')
Also maybe event.bind and event.trigger should have 'Data' appended to
the end to be more clear about what it is.
Also don't forget to clear out any added properties to the event
object in IE or it will leak.
--
Brandon Aaron
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
Brandon Aaron schrieb:
I think I prefer the suggestion made by Dave Methvin of using on() and
un() instead of bind.
$().on('click')
$().un('click')
Thanks Brandon, just forgot to mention that.
Also maybe event.bind and event.trigger should have 'Data' appended to
the end to be more clear about what it is.
Also don't forget to clear out any added properties to the event
object in IE or it will leak.
That's the problem, therefore I favor the paramter approach. While it is
no problem to clean up the added data after the handler was called,
closures could make that ugly. Consider this little example:
$().bind(click, function(event) {
// event.bindData is available here
$().bind(whatever, function() {
// event.bindData is not available!
});
}, {stuff: foobar});
--
Jörn Zaefferer
http://bassistance.de
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
Jörn Zaefferer wrote:
...
The big so far unsolved question: What should the API methods look like?
How to pass the additional data to the event handler?
Currently I favor an interface that looks like this:
$().bind(type of event, eventHandler, {amount: 5, data:
additionalStuff})
$().trigger(type of event, {bubble: true, data: moreStuff});
...
Your opinions?
I hope the event shortcuts will remain, like click( handler ) to bind and
click() to trigger.
As for the bind style, I think the handler should always be the last
argument, because to me it's cleaner this:
$( div ).bind( click, {amount: 1}, function() {
doClick();
} );
than this:
$( div ).bind( click, function() {
doClick();
}, {amount: 1} );
Sure having the function at the bottom makes optional arguments a little
more complitated, and if you think it's better to avoid all those type
checking in the code (I think the same) then the solution is to have no
optional arguments at all, like this:
$( div ).bind( click, {}, function() {
doClick();
} );
This style adds a bit of self-documentation to the script, making it clear
that we are using default values for the second argument.
--
View this message in context:
http://www.nabble.com/jQuery-1.1-API-improvements-%28macros%2C-events%29-tf2713203.html#a7565490
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
On 11/27/06, Andrea Ercolino [EMAIL PROTECTED] wrote:
I hope the event shortcuts will remain, like click( handler ) to bind and
click() to trigger.
They will stick around but in a compatibility plugin.
As for the bind style, I think the handler should always be the last
argument, because to me it's cleaner this:
$( div ).bind( click, {amount: 1}, function() {
doClick();
} );
than this:
$( div ).bind( click, function() {
doClick();
}, {amount: 1} );
I would disagree. It would cause more code in the core and more
confusion. It is pretty universal across libraries and browser that
the paramater order goes: type, method.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
Andrea Ercolino schrieb:
I hope the event shortcuts will remain, like click( handler ) to bind and
click() to trigger.
So far bind() would be on() and unbind() would be un(). The shortcuts
would be removed from the default distribution, but still available as a
compatibility plugin.
As for the bind style, I think the handler should always be the last
argument, because to me it's cleaner this:
$( div ).bind( click, {amount: 1}, function() {
doClick();
} );
than this:
$( div ).bind( click, function() {
doClick();
}, {amount: 1} );
How about this:
var handler = function() { ... };
$(div).bind(click, handler, {amount: 1});
Sure having the function at the bottom makes optional arguments a little
more complitated, and if you think it's better to avoid all those type
checking in the code (I think the same) then the solution is to have no
optional arguments at all, like this:
$( div ).bind( click, {}, function() {
doClick();
} );
This style adds a bit of self-documentation to the script, making it clear
that we are using default values for the second argument.
But the empty object would be still be passed around, creating
unncessary overhead. The default is nothing, therefore you should at
least use null as the second argument. Still I don't like an API that
forces me to pass null around all the time.
--
Jörn Zaefferer
http://bassistance.de
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
Jörn Zaefferer wrote:
So far bind() would be on() and unbind() would be un(). The shortcuts
would be removed from the default distribution, but still available as a
compatibility plugin.
Don't remove the shortcuts, please! They are very convenient for the events.
I can understand that css() and attr() can be enough. But click() as it is
now is Easy and Clear and Convenient. The unbind could be incorporated into
click() too, for example by using click( null );
http://www.nabble.com/jQuery-API-discussion-tf2463514.html#a6867849 as I
suggested before .
Jörn Zaefferer wrote:
How about this:
var handler = function() { ... };
$(div).bind(click, handler, {amount: 1});
OK, it won't be so different after all, having the options at the bottom.
Jörn Zaefferer wrote:
But the empty object would be still be passed around, creating
unncessary overhead. The default is nothing, therefore you should at
least use null as the second argument. Still I don't like an API that
forces me to pass null around all the time.
OK I've already given up on this.
Anyway the default is not nothing, I think it's {amount: infinity} for
events.
--
View this message in context:
http://www.nabble.com/jQuery-1.1-API-improvements-%28macros%2C-events%29-tf2713203.html#a7566749
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
Don't remove the shortcuts, please! They are very convenient
for the events. I can understand that css() and attr() can be
enough. But click() as it is now is Easy and Clear and Convenient.
The unbind could be incorporated into click() too, for example
by using click( null );
Event shortcuts are the major namespace polluter. Each one requires an
implementation, which is usually rather simple, but also documentation. What
about the ability to pass data from the bind or trigger handlers, how would
that be done? If it's not added to these interfaces, then you'll end up with
a mix of .click() and .on(click, fn, {data: whatever}) in the page. If it
is added, then there are a couple of dozen event-methods that require
additional explanation for how they behave.
You can't unbind a single click handler with the .click(null) approach; you
can only unbind all click handlers for the element. That becomes very
important when a page uses multiple plugins that may need event handlers. In
a plugin, you can't assume that just because you want to clear your own
handler that it's okay to clear all of them. It's even a dangerous
assumption to make when developing a page, unless you are familiar with the
internals of all the plugins you are using.
Then there is the classic ambiguity of .unload(). Does it call an onunload
handler, or does it unbind all onload handlers? There is no doubt with
.un(load) or .on(unload, fn) which are only a few characters longer.
Don't worry, nobody is proposing changes that require a fire drill to fix.
There will be a plugin to provide all the 1.1 names and I suspect the
default build will include it for at least a few months to make the
transition easier.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery 1.1 API improvements (macros, events)
The problem with removing all the helper methods is that
some are very heavily used (especially val and click).
While that may reduce jQuery's file size, it will increase
the size of many plugins and pages that use jQuery.
I don't think it will increase plugins or user code by more than a few
characters:
Old: .click(fn)
New: .on(click, fn)
It also eliminates a line or two of runtime checks in the core code, since
the current name overloading has to be disambiguated (Is it setting click
handlers or triggering them?) on each call.
Moving out of core may be a good idea if file size really is
that important ...
It's not just a question of file size, but of namespace pollution,
consistency, and documentation complexity.
...it would still be good if these (or at least the most
used ones) were still part of the default download...
I have a feeling that the compat plugin will have to be part of the standard
1.2 distribution given how many people currently use things like .click()
and .val(). The long term goal is to remove and un-document them from the
core, making them eventually optional; plugin writers should not assume they
are part of the core because that will create a dependency on the compat
plugin and lead to bloat.
$( div ).bind( click, function() {
doClick();
}, {amount: 1} );
It would be more layout-friendly if the function could be the last argument,
since there may be several lines of code in the bound function. The object
at the end gets lost in the code layout. You could check for
arguments.length and decide whether there was an object in the second
argument or not. I can live with either one though.
$().bind(click, function(event, bindData, triggerData) { ... });
This one gets my vote. It saves the cost of extending the event object and
eliminates the risk of clobbering a name in the original event
object--although clobbering some original event properties could be
considered a feature I guess. Just a thought about triggerData: if the
trigger cutoff (amount above) is in there, what effect would it have if
the handler modifies that? (I'm just trying to separate intended from
unintended effects.)
I wonder if it would help to extend [ css() and attr() ] to
allow getting of multiple properties at once. A possible
implementation would accept an array of String and returns
a key/value object, with the values of the array as the keys.
I proposed .attrs() but that was to solve a problem that got solved in
another way. Given the push to shrink and simplify the core, I'd wait until
we find a nail needing that hammer. :-)
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
