Hi,
The first time I saw line 1, I had no clue what it was doing. If all it's
doing is running some jquery before the page is loaded, there's _got_ to be
a more intuitive, succinct way to say it.
That is not, what it is doing. It calls the callback-function as soon as the
document is loaded
Anders,I have to disagree with your view about the readability of jquery. I have little to no knowledge of _javascript_...and the only reason that I started using jquery is because it is so simple to understand the basics (prototype and dojo are a foreign language to mebut jquery is plain
John Resig wrote:
e.g.:
$( '.b0rp' ).filter( '#blap' ).on.click( function() { $( '#foo'
).ajax.load( ... ) } );
Why no just do .onclick() and .ajaxLoad() - like what was proposed?
Not only is it fundamentally easier to write and understand, but it's
easier to implement too.
The
Why not just .request(method, options) or .http()
I like the thought of request to replace the load, get, post functions.
The ajax prefix is to narrow of a definition on what you can do with
that function. In my eyes it also refers to the xmlhttpRequest object.
--
David Duymelinck
I'd like to throw in my support for coalescing all the httprequest stuff
into a request(method,{args}) method. This is much closer to how I
currently do my xhr stuff outside of jquery
Mark Gibson wrote:
Why not just .request(method, options) or .http()
After all AJAX is just a bottle of
Employees International Union
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jörn Zaefferer
Sent: Sunday, October 15, 2006 1:32 PM
To: jQuery Discussion.
Subject: [jQuery] jQuery API discussion
Hi folks,
I'd like to discuss the jQuery API in general
Anders Schneiderman schrieb:
Hi JornjQuer,
As a newbie, my impression is that overall it's a _lot_ simpler and sleeker
than say prototype. And I love the compactness of the language. However,
there are a few aspects that will throw off new folks -- particularly graphic
designers who
Klaus Hartl wrote:
Of course you still have know that you have to pass a function reference
of some kind to click() and the like, but if you want to use an API you
should get familiar with it by reading the documentation to a certain
extend, be it a designer or a programmer. Fortunately
I think that there is space for improvement on both sides of API architecture and its documentation.
We alllike jQuery for how it looks like. We like its chainability, we like its alchemy. So we must preserve what we like mostas much as possible, and doing so we'll also get to an evolution as
The feasibility of 'namespacing' hasn't been brought up yet - but
leave it to be said that it would be really really difficult and add a
ton of overhead to the jQuery base as a whole (in order to continue
chainability support).
Err... I made a rather concrete proposal for how namespacing
On Oct 16, 2006, at 3:01 AM, John Resig wrote:
First, I don't see how just splitting things up into optional plug-
ins really helps the problem. At most, it means that in some rare
cases, collision will be less frequent. But the majority of people
will not want to use jQuery without dom
I think that there's a simpler answer to this.
If we're going to overhaul the API that much, we need to do three things.
1. Talk it out thoroughly, and make sure we get it right this time.
2. Publish a new full release of jQuery (2.0).
3. Put all of the breaking changes at the top of the README.
I could do without namespaces if the build system provided warnings
for collisions instead of silently overwriting.
This way I could add third party and my own plugins without needing
to search the code by hand for conflicts.
I agree that keeping the verbs simple in the API and allowing
On 10/16/06, Sam Collett [EMAIL PROTECTED] wrote:
Not too keen on namespacing (is it really required? will make the code
more verbose and chaining could become confusing),
Namespacing will break readability.
Might as well make John put on some waterski's and find him a shark.
Keep in mind that the namespacing that I'm suggesting is solely for
readability, and should only be used where it makes things more readable.
You're right that it might put some bumps into the chaining, but I think
that making the calls non-colliding and more natural-language-y outweighs
that.
Jörn Zaefferer wrote:
If we go back to the roots and stick to bind(), unbind(), trigger(),
attr() and css(), we could remove all those events and html and css
attribute shortcut methods, greatly reducing the number of methods. By
adding those methods, or rather only parts of it, like
e.g.:
$( '.b0rp' ).filter( '#blap' ).on.click( function() { $( '#foo'
).ajax.load( ... ) } );
Why no just do .onclick() and .ajaxLoad() - like what was proposed?
Not only is it fundamentally easier to write and understand, but it's
easier to implement too.
The feasibility of 'namespacing'
Hi,
And for those lazy sods out there how about:
$.quickMethods({
bind: ['click'],
attr: ['val','href','title'],
css: ['display','height','width']
});
That is a really great idea :-) I think for something so usefull we should
chose a shorter Function-name:
$.fn.q =
Christof -
What Mark is proposing is quite different from what you're proposing.
His function physically creates the helper methods of .click(),
.val(), .href(), .title(), etc.
On a whole, I like the idea - in that it'll make writing the events
plugin painfully easy - but at the same time it'll
$.quickMethods({
bind: ['click'],
attr: ['val','href','title'],
css: ['display','height','width']
});
is sexy. similar to the perl use with parameters.
I can also envision $.quickMethods('all') and even
$.quickMethods(['all','log'])
(for the juniors among us -- me!)
what
Hi,
I would really like if we would maintain the helper methods (even in a
different format like on.click of onclick of on-click. I really don't
care if I have to write ajaxStart or ajax.start or ajax-start, but
namespacing would be nice...).
Abdul
John Resig wrote:
Christof -
What Mark
What Mark is proposing is quite different from what
you're proposing. His function physically creates the
helper methods of .click(), .val(), .href(), .title(), etc.
On a whole, I like the idea - in that it'll make writing the
events plugin painfully easy - but at the same time it'll
Should keep it simple. changing .load to .ajaxLoad is even unneccessary.
e.g.:
$( '.b0rp' ).filter( '#blap' ).on.click( function() { $( '#foo'
).ajax.load( ... ) } );
Why no just do .onclick() and .ajaxLoad() - like what was proposed?
Not only is it fundamentally easier to write and
Should keep it simple. changing .load to .ajaxLoad is
even unneccessary.
None of this is absolutely necessary. jQuery works as-is, and the changes
may break existing code, so the easiest path is to leave everything alone.
The issue is whether we can make changes to the jQuery API that make it
I suggest renaming $.load (the ajax load) to $.update and deprecating
$.post and $.get...
-- Klaus
Jörn Zaefferer schrieb:
Hi folks,
I'd like to discuss the jQuery API in general and the current event API
in detail:
The main problem is the ambiguity of events, unevents and DOM
Mark Gibson schrieb:
While we're on the API:
I really don't like the method name .css(), as its actual
operation is to change a style property, and doesn't really
have much directly to do with Cascading Style Sheets.
Could it not be .style() instead?
Hi Mark,
I don't agree. Styles defined
Hi folks,
I'd like to discuss the jQuery API in general and the current event API
in detail:
The main problem is the ambiguity of events, unevents and DOM methods.
Some examples:
$().unload() - Removes load event handlers AND triggers unload event
$().submit() - Triggers the submit event, but
John Resig schrieb:
$().unload() - Removes load event handlers AND triggers unload event
It actually doesn't do both, it just the last one that was created
(which, I think, is unload). The easiest way of fixing this would be
to rename stuff like 'click' to 'onclick' - that would remove all
I feel there are too many names for the ajax functions they can
all be coded ajax.. and some share names with non ajax function (as
John mentioned)... perhaps new names for these weirdly overloaded
functions?
Which brings up the matter of deprecating... it would be helpful if
you use a
I wouldn't mind loading a script 'jquery-junior-developer-edition.js'
while writing new code!
I'm actually work on this right now. It'll have full type checking for
all jQuery methods along with full console logging. Hopefully this
will also include more-understandable error messages (we'll
First, I don't see how just splitting things up into optional plug-
ins really helps the problem. At most, it means that in some rare
cases, collision will be less frequent. But the majority of people
will not want to use jQuery without dom attributes or events. It can
also result in the ugly
Steven Wittens schrieb:
However, I think we do need to look at actual jQuery use here, as
this is all about convenience. In my own jQuery code (which I'll
admit is not that fancy), I mostly use jQuery objects to bind event
handlers. When I change CSS or DOM properties, it is almost
There are two issues at play here:
1) The collision of method names.
2) The sheer number of methods attached to the jQuery object.
#1 will only be solved through a change in the name of the methods
(for example, from .load() to .onload() or .event.load()).
#2 can only be solved by breaking
Let's assume you are going to do 'something' that makes jQuery better but changes the API.
What is the suggested way to bind a click function or a toggle function NOW so we don't have to change later?
I'd rather change now before things go live. :)
Glen
On 10/15/06, Jörn Zaefferer [EMAIL
deprecated('1.0.2', such and such is deprecated') ... and it gets
removed from the packed/production version, and left in to log in the
junior-developer-edition.
On 10/15/06, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Ⓙⓐⓚⓔ schrieb:
I feel there are too many names for the ajax functions they
35 matches
Mail list logo
