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 function in an old manner, you could get a deprecated
message in the log
if(window.console)
window.console.log(s);
else if (window.opera && window.opera.postError)
window.opera.postError(s)
or whatever you windows folks do .
Of course the heavy hitters and production users don't want that
overhead or the additional size of the js file, so maybe the packed
version does not incude deprecation warnings.
Additional 'assertions' could be sprinkled through the code to assist
us junior devotees about passing the wrong parameters.
I wouldn't mind loading a script 'jquery-junior-developer-edition.js'
while writing new code!
On 10/15/06, John Resig <[EMAIL PROTECTED]> wrote:
> > $().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
> namespace collisions. Back when jQuery was first released, all events
> were mapped to 'onclick' - but I changed this so that backwards
> support with Prototype would be easier.
>
> This would obviously be a big API change, no matter which way we
> decide to spin it.
>
> > $().submit() - Triggers the submit event, but doesn't actually submit
> > anything, that is, it does not (try to) call the submit method of the
> > matched elements. $().blur() and $().focus() have are very similar.
>
> Yep, I noticed this a while ago and created a bug report for it:
> http://jquery.com/dev/bugs/bug/134/
>
> > $().load(Function) - Binds a handler to the load event
> > $().load(String, Hash, Function) - Starts an AJAX request
>
> Again, this could be solved by converting .load(Function) to .onload(Function)
>
> > The ambiguity could be avoided by forcing the user to use bind(),
> > unbind() and trigger(). A reliable solution, but not very sexy.
>
> Forcing is definitely not an option. Splitting off into external
> plugins is much more realizable.
>
> > This is also a general problem of the jQuery API. There are more then
> > 200 API methods, all bound to a single "class". Hell on earth for OO
> > fanatics, but handy if you know what you are doing.
> >
> > 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 click(), back via
> > plugins, the jQuery meat could be reduced to some extend, maybe even
> > reducing the barrier for newcomers by simplifying the API docs.
>
> That's certainly possible - and something that I have been considering
> for a while. The events plugin is already split off (however, I think
> that document.ready should be moved into jquery.js). This way we can
> have (at least) three plugins for dealing with all the helper methods:
> attr.js: Attribute helpers .title(), .href(), etc.
> css.js: CSS helpers .display(), .background()
> event.js: Event helpers .click(), .blur()
>
> This could leave core to simply dealing with traversing and DOM
> manipulation. Everything else would be extraneous. Of course, all of
> this would be a huge change in how things normally work. However, we
> could roll this out in stages:
>
> Step 1) Move attribute and css code into separate files, move document
> ready into jquery.js. Keep attr.js and css.js included in the build
> process.
> Step 2) Make it so that when you download jQuery, you pick which
> official plugins you want to include - attr, css, and event are
> checked by default.
> Step 3) We decide which plugins shouldn't be included with the default
> build and leave them 'unchecked' by default.
>
> > bind(), unbind(), trigger() and attr() could be improved to a hash as
> > css() already does, allowing you to set several attributes at once or
> > adding/removing several events with one method call. Passing a hash
> > without values to attr could be quite sexy, too, when it simply fills
> > the hash with all available values.
>
> That's certainly possible. In the end, we'll have to see how needed it
> really is.
>
> --John
>
> _______________________________________________
> jQuery mailing list
> [email protected]
> http://jquery.com/discuss/
>
--
Ⓙⓐⓚⓔ - יעקב ʝǡǩȩ ᎫᎪᏦᎬ
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
