Re: [jQuery] jQuery 1.1 by the end of Nov
On Nov 15, 2006, at 4:17 AM, John Resig wrote: Hi Everyone - For example: Since the 'form' plugin already does serialization really really well (much better than jQuery's serialization). I'm tempted to remove the serialization plugin from core and just defer everyone to using the form plugin. I need methods to serialize field values on an individual basis or a group which is not encapsulated in a form or for a subset of fields in a form. The Form plugin only exposes serialization on an entire form basis. thanks, ke han Also, stuff like .height() and .width() could be removed in favor of using the (more powerful) methods of the same name in the 'Dimensions' plugin. Let me know if you have any ideas. --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Non-destructive jQuery
I have read Jon's post about a solution to the destructive calls. Being late to the game, I am confused as to the meaning of all this. I sort of understand that some calls are queries and others change things, but what is the impact of this that requires a solution? Is there a thread someone can point me to explaining this or can someone recap the issues? thanks, ke han On Oct 26, 2006, at 10:46 PM, Jörn Zaefferer wrote: Hi folks, I'd really like to see John's modifications to pushStack included in the jQuery core. Details here: http://www.nabble.com/Non- Destructive-jQuery-tf2482924.html I'm actually wondering if that modification would break any existing code, as end() works like before. I guess the only situation is in scenarios like this: var jq = $(); var jq2 = jq.destructiveOperation(); var jq3 = jq.anotherDestructiveOperation(); With the non-destructive pushStack implementation, this would give a different result. Is someone actually using such code? I think this modification is very important to improve the overall jQuery... -- Jörn Zaefferer http://bassistance.de -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery API discussion
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 attributes or events. It can
also result in the ugly situation where, if you decide you need a new
plug-in halfway, you might break existing code because suddenly the
meaning of a method changes.
There are two issues at play here:
1) The collision of method names.
2) The sheer number of methods attached to the jQuery object.
I am new to jQuery, but have been authoring OO app frameworks for 20
years, so have a good feel for when things are balanced. I'm happy
to see this thread pop up now as it address my chief concern.
As to OO design, putting the entire API in jQuery obviously has
negative effects. Notably that not all methods/events are applicable
to all DOM objects (especially for highly custom behaviors).
The explosion of this global namespace is something that one should
be able to opt-out. The recommendation for segmenting by $().css, $
().event, etc may work. Will my plugin be able to provide for my own
new namespace?
I need to create methods and custom events for non-visual helper
objects (which can be found via DOM tree queries). This means that
my plugins will have events and methods which only apply to these
special objects. I would like to write these plugins knowing that I
will not have API conflicts at runtime.
One simple recommendation that would work for me is to provide
warnings in the build/make process for interface conflicts. This
would at least give me some peace of mind (especially for a newcomer
that doesn't know or even plan to use the entire API).
thanks for a very interesting product.
ke han
#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 up the bulk of functions into
multiple plugins. For example, simply breaking off the events plugin
from core will release 100 method names. Additionally, none of these
plugin's method names would conflict with each other - they'd be
entirely separate. (This would be taken care of ahead of time by #1)
Additionally, it would probably be required that plugin authors only
reference functionality in the jQuery core (using .css('height')
instead of .height()) that way their plugin would work with any set of
plugins built in.
--John
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] custom events
I need to add/remove and fire custom events.
As an intro example, I have a div with id TabManager. TabManager
has inside a ul and li's much like others create tabs these days. I
want TabManager to be the central object which other components
listen on for events like tab_changed('new_tab'). TabManager will
also have methods such as query_tab() and change_tab(homeTab).
Sure, I can and have implemented this differently. In prototype, I
just created a javascript class for this and mitigated custom events
through it.
However, in jQuery, it seems wise to try a different approach with a
custom javascript class as a hidden helper object. For a jQuery
approach, TabManager is a referencable DOM object instead of a named
javascript variable.
Any ideas?
thanks, ke han
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery API discussion
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
behavior to be polymorphic could do the trick for most cases.
ke han
On Oct 17, 2006, at 12:05 AM, Sam Collett wrote:
On 16/10/06, Brian Miller [EMAIL PROTECTED] wrote:
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.
Also, from a different branch of the discussion, I'm all for
namespacing.
But, in the case of jQuery, where terseness is one of it's greatest
assets, we should use very selective namespacing.
e.g.
$.ajaxStop() - $.ajax.stop()
$.serialize() - $.form.serialize(), $.xml.serialize()
$.load() - $.on.load(), $.ajax.load()
$.unload - $.on.unload() {unload event}, $.un.load() {remove load
() event}
$.filter - Don't change this. :)
The idea is that we make the names VERY English-intuitive, and
resolve the
name collisions we have using as few characters as possible -
adding only
a dot to an already existing function, if possible/applicable.
Thoughts?
Not too keen on namespacing (is it really required? will make the code
more verbose and chaining could become confusing), but I agree that if
the API changes that much it should be a 2.0 release rather than 1.x.
Breaking changes should be the first thing people see before
downloading (or maybe second after saying why it should be
downloaded).
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
