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/
