[jquery-dev] Re: drag/drop for live events, and is jQuery still accepting minor patches?
I found another way of doing it that is rather sneaky. Maybe someone
else will find it useful. I pull out liveHandler and make my own
live.add function.
var liveHandler = null;
(function(){
var add = jQuery.event.add;
jQuery.event.add = function(el, event, handler, data){
if(data.selector == "stealing" && !event)
liveHandler = handler;
else
add.apply(this, arguments)
}
var f = function(){}, d = {selector: "stealing"}
jQuery.event.add(document, "live",f,d);
jQuery.event.remove(document, "live",f,d);
jQuery.event.add = add;
})();
//hack live to provide what we need
jQuery.event.special.live.add = function( proxy, data, namespaces,
live ) {
jQuery.extend( proxy, data || {} );
proxy.guid += data.selector + data.live;
data.liveProxy = proxy;
jQuery.event.add( this, data.live, liveHandler,
data );
}
On Jan 13, 11:40 pm, Justin Meyer wrote:
> I'm trying to implement drag-drop for live events:
>
> $(".handle").live("dropped", func1);
> $(".drop").live("dropon", func2);
>
> I'm unable to get it working without needing to change jQuery, but not
> significantly. Are these types of patches still going to be accepted?
>
> The problem is that an efficient drag plugin works differently than
> submit / change. It's not just filtering other events. Instead it's
> setting up a variety of events on elements other then the element
> being delegated on, and modifying the element.
>
> Here's my method:
>
> 1. when event.special[dragstart|dragend|dragging].setup is called,
> save a reference to your callback on the delegated element's data
>
> 2. if you are the first event listening for a given selector,
> delegate on mousedown for that selector
>
> 3. When mousedown is called, listen on the document for mousemove and
> mouseup
>
> 4. On mousemove, call dragging handlers for the current selector,
> update the position of the draggable.
>
> 5. On mouseup, call dragend handlers for the current selector.
>
> The problem is that I can't get the original event handler passed into
> live (the proxy). Can special.live.add add the proxy into the
> liveHandler data?
>
> data.liveProxy = proxy;
>
> This is a very minor change, but will allow for a lot of special live
> events. Thanks.
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] drag/drop for live events, and is jQuery still accepting minor patches?
I'm trying to implement drag-drop for live events:
$(".handle").live("dropped", func1);
$(".drop").live("dropon", func2);
I'm unable to get it working without needing to change jQuery, but not
significantly. Are these types of patches still going to be accepted?
The problem is that an efficient drag plugin works differently than
submit / change. It's not just filtering other events. Instead it's
setting up a variety of events on elements other then the element
being delegated on, and modifying the element.
Here's my method:
1. when event.special[dragstart|dragend|dragging].setup is called,
save a reference to your callback on the delegated element's data
2. if you are the first event listening for a given selector,
delegate on mousedown for that selector
3. When mousedown is called, listen on the document for mousemove and
mouseup
4. On mousemove, call dragging handlers for the current selector,
update the position of the draggable.
5. On mouseup, call dragend handlers for the current selector.
The problem is that I can't get the original event handler passed into
live (the proxy). Can special.live.add add the proxy into the
liveHandler data?
data.liveProxy = proxy;
This is a very minor change, but will allow for a lot of special live
events. Thanks.
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] make cleanData available
jQuery.UI and a few other plugins require a 'teardown' callback by
hacking removeData, remove, html, empty, etc.
In 1.4, it would be very easy to hack in teardown if cleanData was
exposed. So something like:
var cd = jQuery.cleanData
jQuery.cleanData = function(elems){
//check elems
for(var i =0; i < elems.length; i++){
var plugins = jQuery.data(elems[i],"plugins")|| {}
for(cname in plugins)
if(typeof plugins[cname].teardown ==
"function") plugins[cname].teardown();
}
cd.apply(this, arguments)
}
would work.
This is extremely easy way to add teardown as everything that might
remove an element calls this method.
If this is something you might accept in 1.4, please let me know and I
will submit a patch. It's really as easy as a find-replace, but I
want to make sure that jQuery.cleanData is an appropriate place for
the function.
Thanks.
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] jQuery Foundation timelines?
It was mentioned at jQCon that jQuery was going to be under a foundation (like Dojo). I've got a client (a Microsoft Shop), that is anxiously waiting for this. Any word on when this is going to happen? I'd also like to move JavaScriptMVC's code into the jQuery foundation. Will this be possible? -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Teardown on plugins
Is there a 'teardown' for plugins that can get triggered automatically
(similar to that for events)?
It's extremely common, and a source of bugs when I see:
$.fn.mySuperPlugin = function(){
...code ...
$(document).click(function(e) { ...code... });
...code...
}
Yes, they should be doing adding/removing this event listener every
time their widget 'comes to life'. But there are cases where even
this doesn't work.
I think I remember John talking about this when we were discussing
"jQuery Enterprise". It was something like:
$.fn.extend("pluginName",{
setup: function( ...),
teardown: function( ...)
})
In JMVC, I've hacked .remove() to enable plugins to write 'teardown'
functionality. For jQuery, when you use the fn.extend function, it
will wrap setup with something that would add teardown to something
like:
$(el).data("plugins")["pluginName"] = teardown.
When remove() is called, it will get all the plugins on the current
element, and call their teardown code.
Someone would also be able to remove a single plugin like:
$(el).data("plugins")["pluginName"]()
Ugly, but the case where you want to remove just one plugin is rare.
Thoughts?
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Ant build
Ah, git is by default CRLFing files. To turn it off: git config core.autocrlf false On Nov 25, 2:33 pm, Justin Meyer wrote: > It works now that I have updated to the latest jQuery. > > On Nov 25, 1:13 pm, Justin Meyer wrote: > > > > > it might be the qunit file that is blocking it. > > > On Nov 25, 12:56 pm,JustinMeyer wrote: > > > > Only sizzle runs for some reason. Likely b/c I am using windows. > > > Does this work for someone else using msysgit? Here's the output: > > > -- > > > $ make > > > Grabbing external dependencies... > > > Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) > > > registered for path 'src/sizzle' > > > Initialized empty Git repository in c:/Development/jquery/src/ > > > sizzle/.git/ > > > remote: Counting objects: 895, done. > > > remote: Compressing objects: 100% (866/866), done. > > > remote: Total 895 (delta 570), reused 57 (delta 10) > > > Receiving objects: 100% (895/895), 449.82 KiB | 159 KiB/s, done. > > > Resolving deltas: 100% (570/570), done. > > > Submodule path 'src/sizzle': checked out > > > '3e97c27d19e18c984a29bfea89fcccadf3544f > > > b3' > > > Building selector code from Sizzle > > > Building ./dist/jquery.js > > > ./dist/jquery.js Built > > > > Building ./dist/jquery.min.js > > > - Compressing using Minifier > > > ./dist/jquery.min.js Built > > > > jQuery build complete. > > > --- > > > -- > > > However, the .gitmodules looks right: > > > > [submodule "test/qunit"] > > > path = test/qunit > > > url = git://github.com/jquery/qunit.git > > > [submodule "src/sizzle"] > > > path = src/sizzle > > > url = git://github.com/jeresig/sizzle.git > > > > Anyone else had this problem? > > > > On Nov 12, 7:46 am, John Resig wrote: > > > > > Actually, both Sizzle and QUnit need to be pulled in dynamically > > > > (using Git submodules). The commands needed to do that are all in the > > > > Makefile and are run automatically before a build occurs. > > > > > --John > > > > > On Thu, Nov 12, 2009 at 8:15 AM, Jörn Zaefferer > > > > > wrote: > > > > > Sizzle lives as a copy in the jQuery repository. QUnit should be > > > > > pulled in > > > > > as a sort of git external, though its required only for testing, not > > > > > for > > > > > making a build of jQuery itself. > > > > > > Jörn > > > > > > On Tue, Nov 10, 2009 at 4:37 AM,JustinMeyer > > > > > wrote: > > > > > >> Does building with Ant work from github anymore? I'm guessing no b/c > > > > >> it needs to get QUnit/Sizzle. > > > > > >> Would it be nice if you could pull in dependencies in JS like ruby's > > > > >> gem install, and all your building would already be done via > > > > >> JavaScript. > > > > > >> Hm ... JMVC has this feature :). > > > > > >> -- > > > > > >> You received this message because you are subscribed to the Google > > > > >> Groups > > > > >> "jQuery Development" group. > > > > >> To post to this group, send email to jquery-...@googlegroups.com. > > > > >> To unsubscribe from this group, send email to > > > > >> jquery-dev+unsubscr...@googlegroups.com. > > > > >> For more options, visit this group at > > > > >>http://groups.google.com/group/jquery-dev?hl=. > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > Groups > > > > > "jQuery Development" group. > > > > > To post to this group, send email to jquery-...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > jquery-dev+unsubscr...@googlegroups.com. > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/jquery-dev?hl=. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Ant build
Now it doesn't work: test/qunit/testrunner.js | 797 test/qunit/testsuite.css | 120 -- test/unit/selector.js| 52 +- 12 files changed, 3124 insertions(+), 3082 deletions(-) create mode 100644 .gitmodules delete mode 100644 Makefile delete mode 100644 libs/jquery.js create mode 100644 test/data/testinit.js create mode 16 test/qunit delete mode 100644 test/qunit/testrunner.js delete mode 100644 test/qunit/testsuite.css >From git://github.com/jquery/qunit * branchmaster -> FETCH_HEAD Updating f55bf2d..4ac535b Fast forward qunit/qunit.js |7 +-- 1 files changed, 1 insertions(+), 6 deletions(-) error: You have local changes to 'test/jquery.js'; cannot switch branches. Unable to checkout '3e97c27d19e18c984a29bfea89fcccadf3544fb3' in submodule path 'src/sizzle' make: *** [init] Error 1 - Notice the test/jquery.js. This is on a fresh install. Am I stupid, or the only person using windows doing this? On Nov 25, 2:33 pm, Justin Meyer wrote: > It works now that I have updated to the latest jQuery. > > On Nov 25, 1:13 pm, Justin Meyer wrote: > > > > > it might be the qunit file that is blocking it. > > > On Nov 25, 12:56 pm,JustinMeyer wrote: > > > > Only sizzle runs for some reason. Likely b/c I am using windows. > > > Does this work for someone else using msysgit? Here's the output: > > > -- > > > $ make > > > Grabbing external dependencies... > > > Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) > > > registered for path 'src/sizzle' > > > Initialized empty Git repository in c:/Development/jquery/src/ > > > sizzle/.git/ > > > remote: Counting objects: 895, done. > > > remote: Compressing objects: 100% (866/866), done. > > > remote: Total 895 (delta 570), reused 57 (delta 10) > > > Receiving objects: 100% (895/895), 449.82 KiB | 159 KiB/s, done. > > > Resolving deltas: 100% (570/570), done. > > > Submodule path 'src/sizzle': checked out > > > '3e97c27d19e18c984a29bfea89fcccadf3544f > > > b3' > > > Building selector code from Sizzle > > > Building ./dist/jquery.js > > > ./dist/jquery.js Built > > > > Building ./dist/jquery.min.js > > > - Compressing using Minifier > > > ./dist/jquery.min.js Built > > > > jQuery build complete. > > > --- > > > -- > > > However, the .gitmodules looks right: > > > > [submodule "test/qunit"] > > > path = test/qunit > > > url = git://github.com/jquery/qunit.git > > > [submodule "src/sizzle"] > > > path = src/sizzle > > > url = git://github.com/jeresig/sizzle.git > > > > Anyone else had this problem? > > > > On Nov 12, 7:46 am, John Resig wrote: > > > > > Actually, both Sizzle and QUnit need to be pulled in dynamically > > > > (using Git submodules). The commands needed to do that are all in the > > > > Makefile and are run automatically before a build occurs. > > > > > --John > > > > > On Thu, Nov 12, 2009 at 8:15 AM, Jörn Zaefferer > > > > > wrote: > > > > > Sizzle lives as a copy in the jQuery repository. QUnit should be > > > > > pulled in > > > > > as a sort of git external, though its required only for testing, not > > > > > for > > > > > making a build of jQuery itself. > > > > > > Jörn > > > > > > On Tue, Nov 10, 2009 at 4:37 AM,JustinMeyer > > > > > wrote: > > > > > >> Does building with Ant work from github anymore? I'm guessing no b/c > > > > >> it needs to get QUnit/Sizzle. > > > > > >> Would it be nice if you could pull in dependencies in JS like ruby's > > > > >> gem install, and all your building would already be done via > > > > >> JavaScript. > > > > > >> Hm ... JMVC has this feature :). > > > > > >> -- > > > > > >> You received this message because you are subscribed to the Google > > > > >> Groups > > > > >> "jQuery Development" group. > > > > >> To post to this group, send email to jquery
[jquery-dev] Re: Ant build
It works now that I have updated to the latest jQuery. On Nov 25, 1:13 pm, Justin Meyer wrote: > it might be the qunit file that is blocking it. > > On Nov 25, 12:56 pm,JustinMeyer wrote: > > > > > Only sizzle runs for some reason. Likely b/c I am using windows. > > Does this work for someone else using msysgit? Here's the output: > > -- > > $ make > > Grabbing external dependencies... > > Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) > > registered for path 'src/sizzle' > > Initialized empty Git repository in c:/Development/jquery/src/ > > sizzle/.git/ > > remote: Counting objects: 895, done. > > remote: Compressing objects: 100% (866/866), done. > > remote: Total 895 (delta 570), reused 57 (delta 10) > > Receiving objects: 100% (895/895), 449.82 KiB | 159 KiB/s, done. > > Resolving deltas: 100% (570/570), done. > > Submodule path 'src/sizzle': checked out > > '3e97c27d19e18c984a29bfea89fcccadf3544f > > b3' > > Building selector code from Sizzle > > Building ./dist/jquery.js > > ./dist/jquery.js Built > > > Building ./dist/jquery.min.js > > - Compressing using Minifier > > ./dist/jquery.min.js Built > > > jQuery build complete. > > --- > > -- > > However, the .gitmodules looks right: > > > [submodule "test/qunit"] > > path = test/qunit > > url = git://github.com/jquery/qunit.git > > [submodule "src/sizzle"] > > path = src/sizzle > > url = git://github.com/jeresig/sizzle.git > > > Anyone else had this problem? > > > On Nov 12, 7:46 am, John Resig wrote: > > > > Actually, both Sizzle and QUnit need to be pulled in dynamically > > > (using Git submodules). The commands needed to do that are all in the > > > Makefile and are run automatically before a build occurs. > > > > --John > > > > On Thu, Nov 12, 2009 at 8:15 AM, Jörn Zaefferer > > > > wrote: > > > > Sizzle lives as a copy in the jQuery repository. QUnit should be pulled > > > > in > > > > as a sort of git external, though its required only for testing, not for > > > > making a build of jQuery itself. > > > > > Jörn > > > > > On Tue, Nov 10, 2009 at 4:37 AM,JustinMeyer > > > > wrote: > > > > >> Does building with Ant work from github anymore? I'm guessing no b/c > > > >> it needs to get QUnit/Sizzle. > > > > >> Would it be nice if you could pull in dependencies in JS like ruby's > > > >> gem install, and all your building would already be done via > > > >> JavaScript. > > > > >> Hm ... JMVC has this feature :). > > > > >> -- > > > > >> You received this message because you are subscribed to the Google > > > >> Groups > > > >> "jQuery Development" group. > > > >> To post to this group, send email to jquery-...@googlegroups.com. > > > >> To unsubscribe from this group, send email to > > > >> jquery-dev+unsubscr...@googlegroups.com. > > > >> For more options, visit this group at > > > >>http://groups.google.com/group/jquery-dev?hl=. > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "jQuery Development" group. > > > > To post to this group, send email to jquery-...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > jquery-dev+unsubscr...@googlegroups.com. > > > > For more options, visit this group at > > > >http://groups.google.com/group/jquery-dev?hl=. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Ant build
it might be the qunit file that is blocking it. On Nov 25, 12:56 pm, Justin Meyer wrote: > Only sizzle runs for some reason. Likely b/c I am using windows. > Does this work for someone else using msysgit? Here's the output: > -- > $ make > Grabbing external dependencies... > Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) > registered for path 'src/sizzle' > Initialized empty Git repository in c:/Development/jquery/src/ > sizzle/.git/ > remote: Counting objects: 895, done. > remote: Compressing objects: 100% (866/866), done. > remote: Total 895 (delta 570), reused 57 (delta 10) > Receiving objects: 100% (895/895), 449.82 KiB | 159 KiB/s, done. > Resolving deltas: 100% (570/570), done. > Submodule path 'src/sizzle': checked out > '3e97c27d19e18c984a29bfea89fcccadf3544f > b3' > Building selector code from Sizzle > Building ./dist/jquery.js > ./dist/jquery.js Built > > Building ./dist/jquery.min.js > - Compressing using Minifier > ./dist/jquery.min.js Built > > jQuery build complete. > --- > -- > However, the .gitmodules looks right: > > [submodule "test/qunit"] > path = test/qunit > url = git://github.com/jquery/qunit.git > [submodule "src/sizzle"] > path = src/sizzle > url = git://github.com/jeresig/sizzle.git > > Anyone else had this problem? > > On Nov 12, 7:46 am, John Resig wrote: > > > > > Actually, both Sizzle and QUnit need to be pulled in dynamically > > (using Git submodules). The commands needed to do that are all in the > > Makefile and are run automatically before a build occurs. > > > --John > > > On Thu, Nov 12, 2009 at 8:15 AM, Jörn Zaefferer > > > wrote: > > > Sizzle lives as a copy in the jQuery repository. QUnit should be pulled in > > > as a sort of git external, though its required only for testing, not for > > > making a build of jQuery itself. > > > > Jörn > > > > On Tue, Nov 10, 2009 at 4:37 AM,JustinMeyer > > > wrote: > > > >> Does building with Ant work from github anymore? I'm guessing no b/c > > >> it needs to get QUnit/Sizzle. > > > >> Would it be nice if you could pull in dependencies in JS like ruby's > > >> gem install, and all your building would already be done via > > >> JavaScript. > > > >> Hm ... JMVC has this feature :). > > > >> -- > > > >> You received this message because you are subscribed to the Google Groups > > >> "jQuery Development" group. > > >> To post to this group, send email to jquery-...@googlegroups.com. > > >> To unsubscribe from this group, send email to > > >> jquery-dev+unsubscr...@googlegroups.com. > > >> For more options, visit this group at > > >>http://groups.google.com/group/jquery-dev?hl=. > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > > "jQuery Development" group. > > > To post to this group, send email to jquery-...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > jquery-dev+unsubscr...@googlegroups.com. > > > For more options, visit this group at > > >http://groups.google.com/group/jquery-dev?hl=. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Ant build
Should qunit be listed in .git/config? http://pitupepito.homelinux.org/?p=24 says that submodules should be listed there. On Nov 25, 12:56 pm, Justin Meyer wrote: > Only sizzle runs for some reason. Likely b/c I am using windows. > Does this work for someone else using msysgit? Here's the output: > -- > $ make > Grabbing external dependencies... > Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) > registered for path 'src/sizzle' > Initialized empty Git repository in c:/Development/jquery/src/ > sizzle/.git/ > remote: Counting objects: 895, done. > remote: Compressing objects: 100% (866/866), done. > remote: Total 895 (delta 570), reused 57 (delta 10) > Receiving objects: 100% (895/895), 449.82 KiB | 159 KiB/s, done. > Resolving deltas: 100% (570/570), done. > Submodule path 'src/sizzle': checked out > '3e97c27d19e18c984a29bfea89fcccadf3544f > b3' > Building selector code from Sizzle > Building ./dist/jquery.js > ./dist/jquery.js Built > > Building ./dist/jquery.min.js > - Compressing using Minifier > ./dist/jquery.min.js Built > > jQuery build complete. > --- > -- > However, the .gitmodules looks right: > > [submodule "test/qunit"] > path = test/qunit > url = git://github.com/jquery/qunit.git > [submodule "src/sizzle"] > path = src/sizzle > url = git://github.com/jeresig/sizzle.git > > Anyone else had this problem? > > On Nov 12, 7:46 am, John Resig wrote: > > > > > Actually, both Sizzle and QUnit need to be pulled in dynamically > > (using Git submodules). The commands needed to do that are all in the > > Makefile and are run automatically before a build occurs. > > > --John > > > On Thu, Nov 12, 2009 at 8:15 AM, Jörn Zaefferer > > > wrote: > > > Sizzle lives as a copy in the jQuery repository. QUnit should be pulled in > > > as a sort of git external, though its required only for testing, not for > > > making a build of jQuery itself. > > > > Jörn > > > > On Tue, Nov 10, 2009 at 4:37 AM,JustinMeyer > > > wrote: > > > >> Does building with Ant work from github anymore? I'm guessing no b/c > > >> it needs to get QUnit/Sizzle. > > > >> Would it be nice if you could pull in dependencies in JS like ruby's > > >> gem install, and all your building would already be done via > > >> JavaScript. > > > >> Hm ... JMVC has this feature :). > > > >> -- > > > >> You received this message because you are subscribed to the Google Groups > > >> "jQuery Development" group. > > >> To post to this group, send email to jquery-...@googlegroups.com. > > >> To unsubscribe from this group, send email to > > >> jquery-dev+unsubscr...@googlegroups.com. > > >> For more options, visit this group at > > >>http://groups.google.com/group/jquery-dev?hl=. > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > > "jQuery Development" group. > > > To post to this group, send email to jquery-...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > jquery-dev+unsubscr...@googlegroups.com. > > > For more options, visit this group at > > >http://groups.google.com/group/jquery-dev?hl=. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Ant build
Only sizzle runs for some reason. Likely b/c I am using windows. Does this work for someone else using msysgit? Here's the output: -- $ make Grabbing external dependencies... Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) registered for path 'src/sizzle' Initialized empty Git repository in c:/Development/jquery/src/ sizzle/.git/ remote: Counting objects: 895, done. remote: Compressing objects: 100% (866/866), done. remote: Total 895 (delta 570), reused 57 (delta 10) Receiving objects: 100% (895/895), 449.82 KiB | 159 KiB/s, done. Resolving deltas: 100% (570/570), done. Submodule path 'src/sizzle': checked out '3e97c27d19e18c984a29bfea89fcccadf3544f b3' Building selector code from Sizzle Building ./dist/jquery.js ./dist/jquery.js Built Building ./dist/jquery.min.js - Compressing using Minifier ./dist/jquery.min.js Built jQuery build complete. - However, the .gitmodules looks right: [submodule "test/qunit"] path = test/qunit url = git://github.com/jquery/qunit.git [submodule "src/sizzle"] path = src/sizzle url = git://github.com/jeresig/sizzle.git Anyone else had this problem? On Nov 12, 7:46 am, John Resig wrote: > Actually, both Sizzle and QUnit need to be pulled in dynamically > (using Git submodules). The commands needed to do that are all in the > Makefile and are run automatically before a build occurs. > > --John > > On Thu, Nov 12, 2009 at 8:15 AM, Jörn Zaefferer > > > > wrote: > > Sizzle lives as a copy in the jQuery repository. QUnit should be pulled in > > as a sort of git external, though its required only for testing, not for > > making a build of jQuery itself. > > > Jörn > > > On Tue, Nov 10, 2009 at 4:37 AM,JustinMeyer > > wrote: > > >> Does building with Ant work from github anymore? I'm guessing no b/c > >> it needs to get QUnit/Sizzle. > > >> Would it be nice if you could pull in dependencies in JS like ruby's > >> gem install, and all your building would already be done via > >> JavaScript. > > >> Hm ... JMVC has this feature :). > > >> -- > > >> You received this message because you are subscribed to the Google Groups > >> "jQuery Development" group. > >> To post to this group, send email to jquery-...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> jquery-dev+unsubscr...@googlegroups.com. > >> For more options, visit this group at > >>http://groups.google.com/group/jquery-dev?hl=. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "jQuery Development" group. > > To post to this group, send email to jquery-...@googlegroups.com. > > To unsubscribe from this group, send email to > > jquery-dev+unsubscr...@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/jquery-dev?hl=. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Ant build
Does building with Ant work from github anymore? I'm guessing no b/c it needs to get QUnit/Sizzle. Would it be nice if you could pull in dependencies in JS like ruby's gem install, and all your building would already be done via JavaScript. Hm ... JMVC has this feature :). -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
[jquery-dev] Re: Fix-less events
The reason is that some events (mousemove/mouseover) I rarely use the
event properties, but the performance of that function is rather
expensive compared to the number of events being fired. Fix might add
300ms of computation for the lifetime of a typical drag/drop event. (I
will happily get better numbers)
This is likely not a concern for most people. But in the app I am
working on, it is the difference between a mouseover/enter looking
instantaneous, or a slight, but annoying lag.
I'm suggesting an additional parameter that will tell the event system
to pass the native event:
$("a").bind("mouseover", { ..data.. }, function(){ ... }, true); ...
true means raw event.
I suppose I should first look if there is a way to speed up fix before
changing the API.
On Nov 5, 8:14 pm, John Resig wrote:
> The only case where that sort-of makes sense is for custom events. I
> mean, there's not much point in not-fixing the event object for some
> events - might as well do it for no events then.
>
> ...unless there's something else that you were considering?
>
> --John
>
>
>
> On Fri, Nov 6, 2009 at 2:43 AM, Justin Meyer wrote:
> > The fix function is rather expensive for things like mousemove and
> > mouseover. Can we make it possible that events won't be fixed for
> > certain events?
>
> > If you like this idea, I'll submit a patch.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "jQuery Development" group.
> > To post to this group, send email to jquery-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jquery-dev+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
[jquery-dev] Fix-less events
The fix function is rather expensive for things like mousemove and mouseover. Can we make it possible that events won't be fixed for certain events? If you like this idea, I'll submit a patch. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
How about $("#something").delegate(".thing","click", func).
It almost makes too much sense :).
On Nov 5, 6:31 pm, Robert Katić wrote:
> I wonder why there would be an $.live with document as the only
> interesting context.
>
> Something like
>
> $(document).zombi(selector, type, ...)
>
> would be more flexible (I know, "zombi" is not nice, but I have no
> inspirations about a more suitable name).
>
> To avoid to repeat selector on multiple bindings, I suggest something
> like:
>
> $(document).make(selector)
> .zombi(type, ...)
> .zombi(type, ...)
>
> An possible implementation of that:http://gist.github.com/227508
>
> Maybe this is only a silly idea for majority of users (now), but I am
> really of idea that this have even more sense then the current
> $.fn.live.
>
> On Nov 5, 2:44 am, xwisdom wrote:
>
>
>
> > Hello,
>
> > Just wondering if version 1.4 will include improvements to live()
> > events.
>
> > See example
> > here:http://www.zachleat.com/web/2009/05/08/performance-caveat-with-jquery...
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Dependency Management and jQuery building
Should getScript have a little dependency management? Should people
to know if they are loading events, that they have to load data?
On Oct 9, 5:54 pm, Justin Meyer wrote:
> I've started working on this. If I remember correctly from the
> conference, core will include just the core.js and getScript. Is this
> correct? The only other potentially likely candidate in my opinion
> would be the ready event.
>
> Thoughts?
>
> On Sep 18, 10:49 am, Justin Meyer wrote:
>
>
>
> > jQuerycore team,
>
> > I was very excited to hear about a possiblejQuerymobile. Keeping
> > file size small is always a concern, and it will be useful for
> > non-mobileprojects as well.
>
> > Further, I don't like having to build every time I make a change in
> > trunk, but then see a giant single file when debugging.
>
> > Are you interested in starting this work now? I'd like to
> > changejQuery'sbuild to use something similar to JMVC's.
>
> > It works by using env.js+rhino to load an html page, find each script
> > tag, and join their contents.
>
> > I'd make each file in /src work independantly (meaning surrounding it
> > with its own (function(){ ... })() with the vars like document,
> > rootQuery, undefined, etc.
> > But when building the single file, each file in /src would have
> > commented if-defs removing those parts.
>
> > The big bonus for the core guys would be developing with logically
> > separated files and not having to build each time. I promise a
> > 3.14159% speed up in core development.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Dependency Management and jQuery building
I've started working on this. If I remember correctly from the
conference, core will include just the core.js and getScript. Is this
correct? The only other potentially likely candidate in my opinion
would be the ready event.
Thoughts?
On Sep 18, 10:49 am, Justin Meyer wrote:
> jQuerycore team,
>
> I was very excited to hear about a possiblejQuerymobile. Keeping
> file size small is always a concern, and it will be useful for
> non-mobileprojects as well.
>
> Further, I don't like having to build every time I make a change in
> trunk, but then see a giant single file when debugging.
>
> Are you interested in starting this work now? I'd like to
> changejQuery'sbuild to use something similar to JMVC's.
>
> It works by using env.js+rhino to load an html page, find each script
> tag, and join their contents.
>
> I'd make each file in /src work independantly (meaning surrounding it
> with its own (function(){ ... })() with the vars like document,
> rootQuery, undefined, etc.
> But when building the single file, each file in /src would have
> commented if-defs removing those parts.
>
> The big bonus for the core guys would be developing with logically
> separated files and not having to build each time. I promise a
> 3.14159% speed up in core development.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Dependency Management and jQuery building
jQuery core team,
I was very excited to hear about a possible jQuery mobile. Keeping
file size small is always a concern, and it will be useful for non-
mobile projects as well.
Further, I don't like having to build every time I make a change in
trunk, but then see a giant single file when debugging.
Are you interested in starting this work now? I'd like to change
jQuery's build to use something similar to JMVC's.
It works by using env.js+rhino to load an html page, find each script
tag, and join their contents.
I'd make each file in /src work independantly (meaning surrounding it
with its own (function(){ ... })() with the vars like document,
rootQuery, undefined, etc.
But when building the single file, each file in /src would have
commented if-defs removing those parts.
The big bonus for the core guys would be developing with logically
separated files and not having to build each time. I promise a
3.14159% speed up in core development.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Event Delegation
That method doesn't work for focus. Focus doesn't bubble in IE, and
you have to use activate. I could check if activate is present and
use that, but it's backwards. But it seems like this is what is done
for XHR:
return window.ActiveXObject ?
new ActiveXObject("Microsoft.XMLHTTP") :
new XMLHttpRequest();
Any other ideas?
On Sep 14, 10:39 pm, Justin Meyer wrote:
> On Kangax's method:
> Perfect, thanks! I'm surprised that works.
>
> On 100s of delegates:
> Well 100s is an exaggeration, but I would guess about 200. There are
> about 40 different components, each responding to about 5 events. The
> components listen regardless if the component is in the page. Someone
> could be adding and removing the delegation if the component must be
> in the page, but managing this defeats the purpose of event delegation
> in the first place.
>
> On Sep 14, 7:23 pm, John Resig wrote:
>
>
>
> > > Best way to listen and remove multiple events for a single delegated
> > > event? (EX: delegate on submit, listen for keypress and click)
>
> > I recommend using special events - this is built in to jQuery core and it's
> > precisely what it's used for (we were planning on using them to implement
> > submit and change delegation).
>
> >http://brandonaaron.net/blog/2009/03/26/special-eventshttp://brandona..
>
> > > How to avoid browser sniffing. (EX: know that submit doesn't bubble in
> > > IE).
>
> > This should be a good
> > pointer:http://thinkweb2.com/projects/prototype/detecting-event-support-witho...
>
> > I was planning on using this technique for submit/change support, as well.
>
> > --John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Event Delegation
On Kangax's method: Perfect, thanks! I'm surprised that works. On 100s of delegates: Well 100s is an exaggeration, but I would guess about 200. There are about 40 different components, each responding to about 5 events. The components listen regardless if the component is in the page. Someone could be adding and removing the delegation if the component must be in the page, but managing this defeats the purpose of event delegation in the first place. On Sep 14, 7:23 pm, John Resig wrote: > > Best way to listen and remove multiple events for a single delegated > > event? (EX: delegate on submit, listen for keypress and click) > > I recommend using special events - this is built in to jQuery core and it's > precisely what it's used for (we were planning on using them to implement > submit and change delegation). > > http://brandonaaron.net/blog/2009/03/26/special-eventshttp://brandonaaron.net/blog/2009/06/4/jquery-edge-new-special-event-... > > > How to avoid browser sniffing. (EX: know that submit doesn't bubble in > > IE). > > This should be a good > pointer:http://thinkweb2.com/projects/prototype/detecting-event-support-witho... > > I was planning on using this technique for submit/change support, as well. > > --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Event Delegation
live.remove is going to have to get passed the stored guids instead of
just counting the remaining 'submits'.
On Sep 14, 5:41 pm, Justin Meyer wrote:
> Another issue is that every live event is stored in $.data
> ('events').live in a flat hash. That means you have to iterate
> through every live event handler instead of just doing something like
> $.data('events').live['click'] -> [list of all delegate selectors]
> which would be much faster, especially if you have 100s of delegated
> events.
>
> I'm not sure what to do about this. I'd like to make the special case
> of live avoid:
>
> handlers[ handler.guid ] = handler;
>
> and instead do
>
> handlers['click'][ handler.guid ] = handler;
>
> Thoughts? I know you guys are busy, but I'd like to know that my work
> might have a chance at being used or is going in the right direction.
> Thanks,
>
> Justin
>
> On Sep 14, 1:15 pm, Justin Meyer wrote:
>
>
>
> > The following avoids browser sniffing for IE's submit.
> > It simply creates a div inside a form, then dispatches a submit event
> > and sees if it bubbles.
>
> > I'll see if something similar works for change in Safari and IE.
>
> > jQuery(function(){
> > var sendEvent = function(type, element){
> > var event;
> > if (element.ownerDocument.createEvent) {
> > event = element.ownerDocument.createEvent("Events");
> > event.initEvent(type, true, true);
> > }
> > else {
> > event = element.ownerDocument.createEventObject();
> > event.type = type;
> > }
> > if(element.dispatchEvent){
> > return element.dispatchEvent(event)
> > }else{
> > try {window.event = event;}catch(e) {}
> > return element.fireEvent('on'+type, event);
> > }
> > }
>
> > var div = document.createElement("div");
> > div.style.display = 'none'
> > div.innerHTML = ""
> > var form = div.firstChild;
> > document.body.appendChild( div );
> > jQuery.support.submitBubbles =false
> > $(div).submit(function(ev){ jQuery.support.submitBubbles =
> > true;ev.stopPropagation()})
> > $(form).submit(function(ev){ ev.preventDefault();})
> > sendEvent("submit",form)
> > document.body.removeChild( div );
> > div = null;
> > form = null;
> > alert(jQuery.support.submitBubbles)
>
> > });
>
> > On Sep 14, 12:16 am, Justin Meyer wrote:
>
> > > WARNING: Skip to the end to avoid an in depth discussion of the
> > > problems, and the only questions I need guidance.
> > >
> > > I'm going to replace JMVC's delegation
> > > lib:http://code.google.com/p/javascriptmvc/source/browse/branches/2_0/jmv...
> > > with live.
>
> > > I've mentioned this once before, but I'm energized after hearing
> > > almost everything I wanted previously is a priority.
>
> > > I was under the impression that the current (trunk?) code supported
> > > submit, but after testing, it seems like it doesn't work in IE. The
> > > code seems to speak to that too. Am I looking in the right place?
>
> > > A few thoughts on live and using delegation. Performance of closest
> > > is critical if you want to support events like mouseover choosing
> > > between > 10 different selectors. In almost all cases, getting the
> > > parentNode list is the most expensive part. This is from a lot of
> > > experience with JMVC, and it only has to calculate this list once. To
> > > support rapid event delegation, I suggest adding a 2nd parameter to
> > > closest which would be a cached array of the parent list.
>
> > > I've been sorta shot down by Brandon, but I don't like having to run a
> > > query when I attach live functions. If I have 10s of thousands of
> > > '.todo' elements on my page (which is the reason I am using live in
> > > the first place), I don't want to have to do a $('.todo'). Using
> > > 'live' is familiar to those who used liveQuery, but delegate would be
> > > a
[jquery-dev] Re: Event Delegation
It seems like I need to be able to store multiple guids in guid.
Would it be better to have it handle if guid is an array, or just add
a guids property?
On Sep 14, 5:41 pm, Justin Meyer wrote:
> Another issue is that every live event is stored in $.data
> ('events').live in a flat hash. That means you have to iterate
> through every live event handler instead of just doing something like
> $.data('events').live['click'] -> [list of all delegate selectors]
> which would be much faster, especially if you have 100s of delegated
> events.
>
> I'm not sure what to do about this. I'd like to make the special case
> of live avoid:
>
> handlers[ handler.guid ] = handler;
>
> and instead do
>
> handlers['click'][ handler.guid ] = handler;
>
> Thoughts? I know you guys are busy, but I'd like to know that my work
> might have a chance at being used or is going in the right direction.
> Thanks,
>
> Justin
>
> On Sep 14, 1:15 pm, Justin Meyer wrote:
>
>
>
> > The following avoids browser sniffing for IE's submit.
> > It simply creates a div inside a form, then dispatches a submit event
> > and sees if it bubbles.
>
> > I'll see if something similar works for change in Safari and IE.
>
> > jQuery(function(){
> > var sendEvent = function(type, element){
> > var event;
> > if (element.ownerDocument.createEvent) {
> > event = element.ownerDocument.createEvent("Events");
> > event.initEvent(type, true, true);
> > }
> > else {
> > event = element.ownerDocument.createEventObject();
> > event.type = type;
> > }
> > if(element.dispatchEvent){
> > return element.dispatchEvent(event)
> > }else{
> > try {window.event = event;}catch(e) {}
> > return element.fireEvent('on'+type, event);
> > }
> > }
>
> > var div = document.createElement("div");
> > div.style.display = 'none'
> > div.innerHTML = ""
> > var form = div.firstChild;
> > document.body.appendChild( div );
> > jQuery.support.submitBubbles =false
> > $(div).submit(function(ev){ jQuery.support.submitBubbles =
> > true;ev.stopPropagation()})
> > $(form).submit(function(ev){ ev.preventDefault();})
> > sendEvent("submit",form)
> > document.body.removeChild( div );
> > div = null;
> > form = null;
> > alert(jQuery.support.submitBubbles)
>
> > });
>
> > On Sep 14, 12:16 am, Justin Meyer wrote:
>
> > > WARNING: Skip to the end to avoid an in depth discussion of the
> > > problems, and the only questions I need guidance.
> > >
> > > I'm going to replace JMVC's delegation
> > > lib:http://code.google.com/p/javascriptmvc/source/browse/branches/2_0/jmv...
> > > with live.
>
> > > I've mentioned this once before, but I'm energized after hearing
> > > almost everything I wanted previously is a priority.
>
> > > I was under the impression that the current (trunk?) code supported
> > > submit, but after testing, it seems like it doesn't work in IE. The
> > > code seems to speak to that too. Am I looking in the right place?
>
> > > A few thoughts on live and using delegation. Performance of closest
> > > is critical if you want to support events like mouseover choosing
> > > between > 10 different selectors. In almost all cases, getting the
> > > parentNode list is the most expensive part. This is from a lot of
> > > experience with JMVC, and it only has to calculate this list once. To
> > > support rapid event delegation, I suggest adding a 2nd parameter to
> > > closest which would be a cached array of the parent list.
>
> > > I've been sorta shot down by Brandon, but I don't like having to run a
> > > query when I attach live functions. If I have 10s of thousands of
> > > '.todo' elements on my page (which is the reason I am using live in
> > > the first place), I don't want to have to do a $('.todo'). Using
> > > 'live' is familiar to those who used liveQuery, but dele
[jquery-dev] Re: Event Delegation
Another issue is that every live event is stored in $.data
('events').live in a flat hash. That means you have to iterate
through every live event handler instead of just doing something like
$.data('events').live['click'] -> [list of all delegate selectors]
which would be much faster, especially if you have 100s of delegated
events.
I'm not sure what to do about this. I'd like to make the special case
of live avoid:
handlers[ handler.guid ] = handler;
and instead do
handlers['click'][ handler.guid ] = handler;
Thoughts? I know you guys are busy, but I'd like to know that my work
might have a chance at being used or is going in the right direction.
Thanks,
Justin
On Sep 14, 1:15 pm, Justin Meyer wrote:
> The following avoids browser sniffing for IE's submit.
> It simply creates a div inside a form, then dispatches a submit event
> and sees if it bubbles.
>
> I'll see if something similar works for change in Safari and IE.
>
> jQuery(function(){
> var sendEvent = function(type, element){
> var event;
> if (element.ownerDocument.createEvent) {
> event = element.ownerDocument.createEvent("Events");
> event.initEvent(type, true, true);
> }
> else {
> event = element.ownerDocument.createEventObject();
> event.type = type;
> }
> if(element.dispatchEvent){
> return element.dispatchEvent(event)
> }else{
> try {window.event = event;}catch(e) {}
> return element.fireEvent('on'+type, event);
> }
> }
>
> var div = document.createElement("div");
> div.style.display = 'none'
> div.innerHTML = ""
> var form = div.firstChild;
> document.body.appendChild( div );
> jQuery.support.submitBubbles =false
> $(div).submit(function(ev){ jQuery.support.submitBubbles =
> true;ev.stopPropagation()})
> $(form).submit(function(ev){ ev.preventDefault();})
> sendEvent("submit",form)
> document.body.removeChild( div );
> div = null;
> form = null;
> alert(jQuery.support.submitBubbles)
>
> });
>
> On Sep 14, 12:16 am, Justin Meyer wrote:
>
>
>
> > WARNING: Skip to the end to avoid an in depth discussion of the
> > problems, and the only questions I need guidance.
> >
> > I'm going to replace JMVC's delegation
> > lib:http://code.google.com/p/javascriptmvc/source/browse/branches/2_0/jmv...
> > with live.
>
> > I've mentioned this once before, but I'm energized after hearing
> > almost everything I wanted previously is a priority.
>
> > I was under the impression that the current (trunk?) code supported
> > submit, but after testing, it seems like it doesn't work in IE. The
> > code seems to speak to that too. Am I looking in the right place?
>
> > A few thoughts on live and using delegation. Performance of closest
> > is critical if you want to support events like mouseover choosing
> > between > 10 different selectors. In almost all cases, getting the
> > parentNode list is the most expensive part. This is from a lot of
> > experience with JMVC, and it only has to calculate this list once. To
> > support rapid event delegation, I suggest adding a 2nd parameter to
> > closest which would be a cached array of the parent list.
>
> > I've been sorta shot down by Brandon, but I don't like having to run a
> > query when I attach live functions. If I have 10s of thousands of
> > '.todo' elements on my page (which is the reason I am using live in
> > the first place), I don't want to have to do a $('.todo'). Using
> > 'live' is familiar to those who used liveQuery, but delegate would be
> > a better name.
> > $().delegate('.todo','click',function(){ ... })
> > But, I realize that this is almost certainly never going to happen.
> > Maybe there can be a $.live where I can provide the context?
>
> > The next suggestion would be adding a stopPropagation to event.
> > LiveHandler would check if it has been called and will simply stop
> > delegated events on the element without returning false from
> > liveHandler. There are many cases where this is needed in our code.
>
> > But getting to the most impo
[jquery-dev] Re: Event Delegation
The following avoids browser sniffing for IE's submit.
It simply creates a div inside a form, then dispatches a submit event
and sees if it bubbles.
I'll see if something similar works for change in Safari and IE.
jQuery(function(){
var sendEvent = function(type, element){
var event;
if (element.ownerDocument.createEvent) {
event = element.ownerDocument.createEvent("Events");
event.initEvent(type, true, true);
}
else {
event = element.ownerDocument.createEventObject();
event.type = type;
}
if(element.dispatchEvent){
return element.dispatchEvent(event)
}else{
try {window.event = event;}catch(e) {}
return element.fireEvent('on'+type, event);
}
}
var div = document.createElement("div");
div.style.display = 'none'
div.innerHTML = ""
var form = div.firstChild;
document.body.appendChild( div );
jQuery.support.submitBubbles =false
$(div).submit(function(ev){ jQuery.support.submitBubbles =
true;ev.stopPropagation()})
$(form).submit(function(ev){ ev.preventDefault();})
sendEvent("submit",form)
document.body.removeChild( div );
div = null;
form = null;
alert(jQuery.support.submitBubbles)
});
On Sep 14, 12:16 am, Justin Meyer wrote:
> WARNING: Skip to the end to avoid an in depth discussion of the
> problems, and the only questions I need guidance.
>
> I'm going to replace JMVC's delegation
> lib:http://code.google.com/p/javascriptmvc/source/browse/branches/2_0/jmv...
> with live.
>
> I've mentioned this once before, but I'm energized after hearing
> almost everything I wanted previously is a priority.
>
> I was under the impression that the current (trunk?) code supported
> submit, but after testing, it seems like it doesn't work in IE. The
> code seems to speak to that too. Am I looking in the right place?
>
> A few thoughts on live and using delegation. Performance of closest
> is critical if you want to support events like mouseover choosing
> between > 10 different selectors. In almost all cases, getting the
> parentNode list is the most expensive part. This is from a lot of
> experience with JMVC, and it only has to calculate this list once. To
> support rapid event delegation, I suggest adding a 2nd parameter to
> closest which would be a cached array of the parent list.
>
> I've been sorta shot down by Brandon, but I don't like having to run a
> query when I attach live functions. If I have 10s of thousands of
> '.todo' elements on my page (which is the reason I am using live in
> the first place), I don't want to have to do a $('.todo'). Using
> 'live' is familiar to those who used liveQuery, but delegate would be
> a better name.
> $().delegate('.todo','click',function(){ ... })
> But, I realize that this is almost certainly never going to happen.
> Maybe there can be a $.live where I can provide the context?
>
> The next suggestion would be adding a stopPropagation to event.
> LiveHandler would check if it has been called and will simply stop
> delegated events on the element without returning false from
> liveHandler. There are many cases where this is needed in our code.
>
> But getting to the most important question - how to get submit and
> change working?
>
> For submit and change, you have to listen to multiple events (and
> later be able to stop listening). It doesn't seem there is a good way
> to do this in event.add. What would be the best way of doing this?
>
> JMVC uses before and after filters for certain event / browser pairs
> to make sure things are ok. For example, in IE you listen for clicks
> + keypress instead of submit. The beforeFilter makes sure the target
> is an submit input.
>
> For change in IE on a select, I listen for clicks, make sure the
> selector matches the element, then the after filter checks if there is
> a value (in $.data("_change_data")). If not, there hasn't been a
> change, so it saves the current value. If there is a value, and it is
> different, the filter 'approves' the change.
>
> There are a few issues with this. The most important is that I am
> browser sniffing like crazy. I'm not sure if this can be done w/o
> browser sniffing. The only thing I think could even work is creating
> a form, dis
[jquery-dev] Event Delegation
WARNING: Skip to the end to avoid an in depth discussion of the
problems, and the only questions I need guidance.
I'm going to replace JMVC's delegation lib:
http://code.google.com/p/javascriptmvc/source/browse/branches/2_0/jmvc/plugins/dom/delegate/delegate.js
with live.
I've mentioned this once before, but I'm energized after hearing
almost everything I wanted previously is a priority.
I was under the impression that the current (trunk?) code supported
submit, but after testing, it seems like it doesn't work in IE. The
code seems to speak to that too. Am I looking in the right place?
A few thoughts on live and using delegation. Performance of closest
is critical if you want to support events like mouseover choosing
between > 10 different selectors. In almost all cases, getting the
parentNode list is the most expensive part. This is from a lot of
experience with JMVC, and it only has to calculate this list once. To
support rapid event delegation, I suggest adding a 2nd parameter to
closest which would be a cached array of the parent list.
I've been sorta shot down by Brandon, but I don't like having to run a
query when I attach live functions. If I have 10s of thousands of
'.todo' elements on my page (which is the reason I am using live in
the first place), I don't want to have to do a $('.todo'). Using
'live' is familiar to those who used liveQuery, but delegate would be
a better name.
$().delegate('.todo','click',function(){ ... })
But, I realize that this is almost certainly never going to happen.
Maybe there can be a $.live where I can provide the context?
The next suggestion would be adding a stopPropagation to event.
LiveHandler would check if it has been called and will simply stop
delegated events on the element without returning false from
liveHandler. There are many cases where this is needed in our code.
But getting to the most important question - how to get submit and
change working?
For submit and change, you have to listen to multiple events (and
later be able to stop listening). It doesn't seem there is a good way
to do this in event.add. What would be the best way of doing this?
JMVC uses before and after filters for certain event / browser pairs
to make sure things are ok. For example, in IE you listen for clicks
+ keypress instead of submit. The beforeFilter makes sure the target
is an submit input.
For change in IE on a select, I listen for clicks, make sure the
selector matches the element, then the after filter checks if there is
a value (in $.data("_change_data")). If not, there hasn't been a
change, so it saves the current value. If there is a value, and it is
different, the filter 'approves' the change.
There are a few issues with this. The most important is that I am
browser sniffing like crazy. I'm not sure if this can be done w/o
browser sniffing. The only thing I think could even work is creating
a form, dispatching a synthetic 'submit' event via fireEvent/
dispatchEvent. Obviously, that would suck and I am not sure it will
even work. I'm open to suggestions before I try.
The second issue is that I am putting data in _change_data. Is there
a better place for this?
Another thing, you need to have capture option passed to event.add so
focus and blur will work.
event.add = function(elem, types, handler, data, capture){ ...}
Would this be ok?
-
So, I can happily build all of this if I can get guidance on the 2
most important problems:
Best way to listen and remove multiple events for a single delegated
event? (EX: delegate on submit, listen for keypress and click)
How to avoid browser sniffing. (EX: know that submit doesn't bubble in
IE).
Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] JavaScriptMVC 2.0
(Disclaimer: I was not able to continue the previous thread -
http://groups.google.com/group/jquery-dev/browse_thread/thread/1ec4dca6e02616d6)
Dear jQuery Community,
We've just finished the first stable release of JavaScriptMVC 2.0
(http://javascriptmvc.com) and I couldn't be more please with the
result. I've posted a 12 min video that walks through getting started
( http://cdn.javascriptmvc.com/videos/2_0/2_0_demo.htm ).
It includes everything I mentioned in the original post:
- A standard way of organizing files
- Compression
- Documentation
- Testing
- Code generators
- Scaffolding for easily connecting to services
- Command line plug-in installation and dependency management.
- A powerful class system (based off Resig's class)
2.0's feature set is similar to 1.5 with 3 important exceptions:
1. jQuery integration and API improvement. I tried very hard to
'jQuery-ify' JavaScriptMVC. Everything (with the exception of
include) is under the jQuery namespace. I've tightened and eliminated
much of the old API. Controllers add themselves to the jQuery
namespace and into jQuery data. For a single contrived example:
$.Controller.extend('TodoController',{
".show mouseover" : function(el, ev){
el.addClass('over');
}
})
To add TodoController 'powers' to any element of the dom:
$('.todos').todo_controller();
2. Testing. 2.0 integrates Selenium, Rhino, and Browser based
testing. This means you can write your tests so they work in the
browser, then they will instantly run in selenium and rhino.
3. The documentation engine was re-engineered to work like Remy
Sharp's jQuery API Browser (http://api.jquery.com). However, the docs
are completely JavaScript, written in JMVC. In fact, the entire
http://javascriptmvc.com site is just JMVC's documentation.
If you have 20 min, walk through the getting started
guide. It touches on most of the
important concepts and tools packed in JMVC.
I still would like to see JMVC become part of the jQuery team. I
believe that Thin Server Architecture is how apps will be built. This
is going to force more code and developers on the client. In my
experience, this creates havoc that no amount of documentation or a
jQuery 'lint' would correct.
Becoming part of jQuery can, and should, only happen if there is a
demand for these problems to be solved. Not everyone is building
Gmail. Most are using a few scripts to add a lightbox here and an
animation effect there. However, it's possible to for jQuery to have
a smooth gradient from adding simple hover effects to full blown, 100k
lines-of-code, monster apps.
If you have ideas on ideas for the next version (2.1), I'd love to
hear them. Thanks,
Justin Meyer
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] window['eval']() in rhino
I assume there must be a good reason, but why is window['eval'] used as opposed to window.eval in httpData? This has some issues in rhino for reasons discussed here: http://www.mail-archive.com/dev-tech-js-engine-rh...@lists.mozilla.org/msg00664.html I know jQuery's tests run in rhino, but perhaps not XHR JSON requests? Is there something that you are doing to rhino (I'm not in strict mode) that allows this? Thanks for your help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Tres,
Besides plugining your own framework is there a reason why you don't
think JMVC is for jQuery? You yourself even express the needed for
tighter control of jQuery and have gone as far as building your own
tool.
At it's center I a proposing a standard way of organizing the only
things a JavaScript application actually does:
Respond to events
Request data / manipulate services/ Ajax
Wrap the service data
Update the DOM.
Why do you think JavaScriptMVC is over doing it? Because it is more
than one file? That is actually a huge advantage ... it allows
developers to add only the functionality they need without having to
worry about compression.
If you are going to share a 'harsh opinion' please provide reasons for
why the above Controller and View wouldn't be useful. If you can, I
think you'd be the first person who doesn't like them - especially
controller ... I mean, just look at that syntax ... your function
names are what they respond to ... and who doesn't like event
delegation? In fact, I'll take the pepsi challenge and promise that
with JMVC's tools that I can create easier to understand and modify
code, faster, than with jQuery alone.
John has posted some valid points about how some of JMVC's features,
namely class, could invade the core. However, I'm not sure if even
John has worked on projects as large and complex as those that have
prompted JMVC. In these projects, a wiki of suggestions is not going
to be enough to refine a large group of limited skill developers code
so that it is maintainable.
However, for the (lucky?) few that find themselves losing the reins of
apps that make Gmail look small, there will be an jQuery based
solution for them. I'm hoping to find a few who are willing to help
me perfect the tools and techniques.
If you do want to explore these techniques I'm super pumped to work
with you. Just let me know what you think jQuery needs. However,
more than one file is a good thing :).
@DBJ 2-4 is all done in JMVC. Please let me know if you have any
comments on the above syntax.
On Apr 28, 8:07 am, tres wrote:
> Justin,
>
> I think you have some good points about what you are trying to
> achieve, but personally, I don't think jMVC is for jQuery. I would be
> interested in collaborating on some projects such as this in the
> jQuery realm, though. I have done a bit of development on something
> similar (although, it's one JS file ;) ) and have recently implemented
> the execution of javascript files withing the context of part of the
> DOM as well as (previously) lazy loading, caching and namespacing
> while taking bits from ruby on rails, zend as well as my personal php
> mvc framework.
>
> Sorry. Harsh opinion, but I wouldn't be me without it. If your
> interested on working on some projects (as well as other people), I'd
> love to hear back from you.
>
> --
> Trey
>
> On Apr 28, 4:40 pm, Justin Meyer wrote:
>
> > If anyone out there is still interested ... I just put up the first
> > alpha. It's pretty slick. You can find it here:
>
> >http://javascriptmvc.com/wiki/index.php?title=Downloads
>
> > I re-mapped JMVC's Controller, View, and Class to work nicer with
> > jQuery. And, compression works with the latest env.js.
>
> > Here's how class basically works:
>
> > $.Class.extend("Name.Of.MyClass",{
> > static : function(){return 'static' }},{
>
> > init : function( val){
> > this.val = val;
> > }
> > proto : function(){ return this.val }
>
> > })
>
> > Name.Of.MyClass.static() // -> static
> > new Name.Of.MyClass(''proto').proto() // -> proto
> > Name.Of.MyClass.extend("NewClassName",{},{}) //-> NewClassName
>
> > Here's how a very simple 'show content' controller could work:
>
> > $.Controller.extend("ShowController",{},{
> > 'a click' : function(el, ev){
> > var id = el.attr('href'); //get id we want to show
> > this.element.find(id ).toggle(); //find it inside the 'wrapped'
> > element
> > ev.preventDefault() //prevent browser from auto-scrolling there
> > }
>
> > })
>
> > You could add this to any collection of a's like the following:
>
> >
> > Open
> > Blah Blah
> >
>
> > $('#mycollection').show_controller();
>
> > Honestly ... what could be better than that I mean really. That
> > has got to be the nicest way of defining and grouping functionality
> > just about ever.
>
> > A few more things about this.
>
> > When you 'add' show controller
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
If anyone out there is still interested ... I just put up the first
alpha. It's pretty slick. You can find it here:
http://javascriptmvc.com/wiki/index.php?title=Downloads
I re-mapped JMVC's Controller, View, and Class to work nicer with
jQuery. And, compression works with the latest env.js.
Here's how class basically works:
$.Class.extend("Name.Of.MyClass",{
static : function(){return 'static' }
},{
init : function( val){
this.val = val;
}
proto : function(){ return this.val }
})
Name.Of.MyClass.static() // -> static
new Name.Of.MyClass(''proto').proto() // -> proto
Name.Of.MyClass.extend("NewClassName",{},{}) //-> NewClassName
Here's how a very simple 'show content' controller could work:
$.Controller.extend("ShowController",{},{
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
You could add this to any collection of a's like the following:
Open
Blah Blah
$('#mycollection').show_controller();
Honestly ... what could be better than that I mean really. That
has got to be the nicest way of defining and grouping functionality
just about ever.
A few more things about this.
When you 'add' show controller to mycollection it does the following:
adds the class name 'show_controller' to mycollection making it easy
to figure out what controllers are responding to mycollection just by
inspecting the dom.
puts the controller in the element's data so you can get it like:
$('#mycollection').data('show_controller')
And remove all functionality like:
$('#mycollection').data('show_controller').destroy();
You can also have 'setup' functionality. Lets say we wanted to hide
everything in our element that matched some selector, we could add an
init function:
$.Controller.extend("ShowController",{},{
init : function(element, hideSelector){
this._super(element); //sets the element to delegate from and
this.element
this.element.find(hideSelector).hide()
},
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
now we could call it like:
$('#mycollection').show_controller('p');
How fantastic is that. This can be better for jQuery that the jersey
we gave John.
And if you wanted to extend the functionality and make it your own:
ShowController.extend("MyShowController",{},{
'a click' : function(el, ev){
this._super(el, ev)
el.text( el[0].style.display == "" ? "hide" : "show" ) //says
hide or show
}
})
Oh, I almost forgot views:
$(".some_thing").append({view '/url/to/view', data: {message:
"hello_world"}})
in /url/to/view.ejs
<%= message %>
prepend, after, before,replace,text,html all work too.
Now that I got a rough draft ... I'm really looking for people who
want to take this project to the next level with me. Give me a shout
if you are interested and what you think -> justinbme...@gmail.com
John, let me know if there is a better place for this. It's very
jQuery related, but don't want to be spamming anyone.
My next step is hardening the API and getting rhino and selenium
testing working.
On Mar 1, 7:33 am, tres wrote:
> I realized after I made my last post (#57) I realized that you
> described almost exactly what I had just built :). Sort of like
> finding money behind the couch!
> Try:http://code.google.com/p/jquery-plugin-dev/source/browse/trunk/jquery
>
> Anyways, I am not trying to say MVC is over-engineering in practice as
> I do understand the need for organization, code-reuse and convention
> (I've authored my own PHP5 MVC framework), but currently I think that
> with JavaScript, there needs to be a happy medium between performance,
> organization and convention. Separating these out into at least 3
> server calls per page, plus extra processing time that comes from
> dispatching and routing, has the potential for a bit of overhead,
> especially in a large application.
>
> UI, being as dynamic as it is, calls for many different situations
> where you might respond to an event by posting a form via ajax, and
> when that is done manipulating the DOM accordingly. As simple as that
> seems, more often than not something will vary with the way JavaScript
> will have to handle the user's last interaction
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
@Trey,
You created a plugin to deal with the exact problems we have been
talking about :).
Have you developed a JS centered application, something that could
be considered a 'Thin-Server-Architecture' app?
When you build the entire HTML structure client side, a lack of a JS
template (View) is brutal.
If you only have raw services to work from, something that can wrap
and provide context to the data is essential.
Although widget.js comes close to a 'controller' anyway, wouldn't it
be great if you can make plugins like:
$.plugin('todo',{
init : function(element, options) {
//initialization code on the element
//uses something in 'data' as 'this' for state, instead of
this=element
this.created = true;
}
"a.destroy click" : function(element, event){
//uses event delegation to call without actually having to setup
delegation
this.destroyed = true;
},
destroyed : function(){ return this.destroyed } // a normal function
on the plugin
})
Widget.js could just see which functions look for events and setup
delegation on the element for you.
Now, what if you can create your plugin like:
var instances = $('.someClass').todo(options)
and it would return the 'instances' of the plugin you were operating
on so you could do something like:
instances[0].destroyed();
MVC isn't over-engineering in a 'large' project because it fits
perfects with what you always have to do.
-respond to events
-connect to/manipulate services
-wrap data from those services
-Build/manipulate HTML/DOM
Logically separating these concerns is extremely helpful. Doing it in
an organized and repeatable fashion is event more important.
@nicolas - I was never implying any of this should be part of the
core. It should not be. I was simply proposing that a new 'branch'
of jQuery is started with a focus on tools and structure needed for
large projects.
On Feb 25, 6:11 pm, tres wrote:
> I think 'MVC as it states - Model, View, Controller - in JavaScript
> terms, is over-engineering what doesn't need to be over-engineered.
> jQuery in it's simplicity can evolve with a very complex application
> quite nicely.
>
> That being said, I have authored myself a plugin called jFrame in
> order to help with code convention, organization as well as automated
> loading. Works nicely for me.
>
> -Trey
>
> On Feb 25, 8:26 am, John Resig wrote:
>
> > Ok, so boiling down a list:
>
> > Needs code:
> > - Widget utility (I'm working on this)
> > - Debugging utility
> > - Static plugin analyzer
>
> > Need a tutorial to cover the concepts of (I'm working on this):
> > - Encapsulation
> > - Extensibility
> > - Modularity
>
> > Needs (defined/documented) conventions:
> > - File names
> > - Method names
> > - Method structures
> > - Testing
> > - Documentation
> > - Packaging
>
> > Once the above conventions are finalized, that static plugin analyzer
> > can be written.
>
> > Once the widget code is done, the tutorial needs to be updated.
>
> > ---
>
> > So, with that drawn in the sand, Justin, would you be interested in
> > working on the debugging plugin, the static analyzer, defining
> > conventions, all of the above?
>
> > Any/all of those would be a huge help and I'd imagine that if the work
> > is solid they should all become official jQuery projects/conventions.
>
> > Now I'm not discounting any additional code or patterns but we need to
> > start with what we have and make sure that we're working with the best
> > possible resources. If we define the above conventions and code we may
> > find that there is less of a need for a new project than we originally
> > thought - and we get the benefit of having excellently defined and
> > documented resources and conventions for people to use - so everyone
> > wins.
>
> > --John
>
> > On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer
> > wrote:
>
> > >> - package and minimize multiple files (YUI Compressor)
>
> > > - Could be solved much better as it is not integrated into the
> > > 'framework'. You have to 'double' include everything (once in your
> > > page, another in your build script). You have to set your html to
> > > switch from loading separate files to loading the combined in
> > > production.
>
> > >> - documentation (jQuery Documentation Wiki - already allows devs to
> > >> have inline demos and can be extracted to external sources)
>
> > > Unless I am misunderstanding something, does this allow me t
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
John, I am potentially interested. I'm concerned that what you are proposing would be a step back in helping large application development. There are a few reasons: 1. Some of jQuery's current conventions might hurt large projects (I've seen far too much added to $ and jQuery.fn ). Without code/ support for 'model' and 'view' type concerns, I think that these important components will be ignored. 2. There are 'better' solutions to some problems - like JMVC's include compared to ShrinkSafe alone. JMVC makes use of ShrinkSafe, but adds automatic compression to it. I think JMVC's controller is also 'better' at encapsulating event handling than widget.js. I am not attached to jQuery or its current user base. I want to deliver the best framework possible without much concern for prior-art for its own sake. I understand you have to protect your community center. 3. Most importantly, a single, integrated package is critical. It drives the development of the parts together. Plus, forcing testing and documentation isn't a bad thing. Well, I feel like the nerd after getting rejected by the prom queen. In movies, she always end up with him after he works real hard, makes his millions, and experiences some much needed personal and physical growth. It appears that I must travel this road. I would like to continue the discussion as a jQuery plugin. I submitted it to the plugins forum. I will add a link when/if this gets approved. On Feb 24, 3:26 pm, John Resig wrote: > Ok, so boiling down a list: > > Needs code: > - Widget utility (I'm working on this) > - Debugging utility > - Static plugin analyzer > > Need a tutorial to cover the concepts of (I'm working on this): > - Encapsulation > - Extensibility > - Modularity > > Needs (defined/documented) conventions: > - File names > - Method names > - Method structures > - Testing > - Documentation > - Packaging > > Once the above conventions are finalized, that static plugin analyzer > can be written. > > Once the widget code is done, the tutorial needs to be updated. > > --- > > So, with that drawn in the sand, Justin, would you be interested in > working on the debugging plugin, the static analyzer, defining > conventions, all of the above? > > Any/all of those would be a huge help and I'd imagine that if the work > is solid they should all become official jQuery projects/conventions. > > Now I'm not discounting any additional code or patterns but we need to > start with what we have and make sure that we're working with the best > possible resources. If we define the above conventions and code we may > find that there is less of a need for a new project than we originally > thought - and we get the benefit of having excellently defined and > documented resources and conventions for people to use - so everyone > wins. > > --John > > On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer wrote: > > >> - package and minimize multiple files (YUI Compressor) > > > - Could be solved much better as it is not integrated into the > > 'framework'. You have to 'double' include everything (once in your > > page, another in your build script). You have to set your html to > > switch from loading separate files to loading the combined in > > production. > > >> - documentation (jQuery Documentation Wiki - already allows devs to > >> have inline demos and can be extracted to external sources) > > > Unless I am misunderstanding something, does this allow me to document > > my application, or is this just for jQuery? I am talking about > > something similar to JSDoc. > > >> - testing (QUnit) > > > Does it handles synthetic events? Can it run server-side to ensure > > sanity before checkin? Can you do point and click testing like > > selenium? > > >> > Where do I put the files? > >> > What should I name the files? > > >> I'm not completely convinced that this is a huge problem - but at > >> worst this could be solved through convention and documentation. > > >> > How/where should I respond to events? > >> > How should I deal with state? > >> > How can I maximize the chances of re-usability? > > >> All three of these are handled either through better documentation or > >> with the widget/jQuery.plugin code that I showed earlier (it > >> especially helps to deal with state and reusability, while responding > >> to events would be more of a documentation issue). > > > Yes, these conventions are exactly what is needed. Documentation can > >
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
JS is Object Oriented. So are we really just talking about classical inheritance (and even more specific, _super) ? I see how widget.js creates a plugin. But how does one expand on the plugin? I'm more than happy with widget.js if you can easily expand on the widget. For example, quickly added a delegated hoverenter that will show a tooltip, or change an existing function. I don't think super is necessary at all. I've only used it a few times, never needed it. But if you let go of _super, and you are able to easily expand the widget, how is that different than what you are considering OOP? On Feb 24, 1:22 pm, John Resig wrote: > > Quick comments: > > > On OOP and not being convinced. What other approaches are you hinting > > at? OOP being well understood is a valid argument only because > > inheritance and OO does provide reuse. If you have something that > > does work in many cases, you are allowed to factor in popularity and > > understandability. > > For example, the widget plugin that I pointed to. I keep talking about > it so I'll just link to it > again:http://dev.jquery.com/~john/plugins/widget/widget.js > > This is a case where many of the problems (or complexities) that exist > in advanced jQuery plugins are already taken care of: extensibility, > encapsulation, and reusability. > > I consider this to be a good example of introducing a selective piece > of jQuery functionality that'll help developers but without doing a > wholesale import of OOP techniques. > > > Why do you think this would contribute to jQuery bloat anymore than > > jQuery.UI does? > > Because jQuery UI isn't, or doesn't, have the ability to become a > dependency for nearly every plugin created. As I mentioned before, > most developers look at the tool of Classes as the be-all and end-all > of development patterns. Introducing that in a sanctioned manner will > instantly make it a dependency of countless plugins, at which point we > would be required to include it in core, out of necessity. It seems > like it would be a much better option to produce a plugin/widget > construction utility that solves all the problems that advanced jQuery > developers encounter, in a style that meshes well with the jQuery > philosophy, rather than a wholesale import of OOP concepts. > > --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
> - package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. > - documentation (jQuery Documentation Wiki - already allows devs to > have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. > - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? > > Where do I put the files? > > What should I name the files? > > I'm not completely convinced that this is a huge problem - but at > worst this could be solved through convention and documentation. > > > How/where should I respond to events? > > How should I deal with state? > > How can I maximize the chances of re-usability? > > All three of these are handled either through better documentation or > with the widget/jQuery.plugin code that I showed earlier (it > especially helps to deal with state and reusability, while responding > to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. > > Where should I be connecting to the service? > > That's probably outside the scope of anything that we would do, since > it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. > > How can I wrap the service data? (For example, maybe the todo has > > passed it's completion date and you want to ask it .isPastDue(). > > This seems like another case of encapsulation or dealing with state (imo). > > > How can I create HTML in a readable manner? > > At best, something that's done through convention. Yes, but where should that html go, etc. Yes, convention is needed. I guess that is the central point we've arrived at. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Quick comments: On OOP and not being convinced. What other approaches are you hinting at? OOP being well understood is a valid argument only because inheritance and OO does provide reuse. If you have something that does work in many cases, you are allowed to factor in popularity and understandability. Why do you think this would contribute to jQuery bloat anymore than jQuery.UI does? On Feb 24, 12:40 pm, Justin Meyer wrote: > John, > Thanks for your reply! You are absolutely right that we need to > discuss which problems are difficult to solve. > > Is it safe to say that you agree that jQuery says very little about > how to : > - package and minimize multiple flies > - document > - test > - dependency management > - log errors / debugging tools ? > > Often developers are forced to pick from many completing plugins or > 3rd party libraries. Similar to jQuery.UI this 'jQuery Enterprise' > would provide a standard set of tools and come in a single integrated > package. I think it's fair to say that this could bolster JS > development just as much as an Accordion or Datepicker. > > On to separating concerns and providing reuse, > > It's very possible to separate concerns with jQuery/Prototype, or any > other library, server or clientside. However, a good 'framework' > forces that upon developers (but lets them escape it if necessary) in > one standard way. > > The issue is that the developer has far too many choices. Consider > the case of building a todo widget that connects to some backend > service. > > Where do I put the files? > What should I name the files? > How/where should I respond to events? > How should I deal with state? > How can I maximize the chances of re-usability? > Where should I be connecting to the service? > How can I wrap the service data? (For example, maybe the todo has > passed it's completion date and you want to ask it .isPastDue(). > How can I create HTML in a readable manner? > > Giving this problem and jQuery to a novice developer will not result > in similar code twice. If you want to enable broad code sharing, all > these questions should have an answer. The jQuery/JMVC project I am > consulting on now has about 300 files. If there is functionality I > need to modify, I know, almost w/o exception where it has to be and > how it is built. > > Getting to this point isn't a matter of documentation on jQuery's > part. If you have to document it to get people to use it, people > won't do it. You have to force people to do things a specific way > (hence why generators became part of JMVC). > > In Scalable jQuery, you noted: > > # That the vast majority of what everyone does is directly related to > the DOM. > # That for the rare cases in which a pure-JavaScript structure is > required, the plain JavaScript language is sufficient for meeting most > needs. > > In my opinion, it is not rare on large projects. Much more logic goes > into if a button is visible or can be clicked than into creating it > and attaching an event. > > It's exactly because jQuery has done such an amazing job at solving IF > we can build anything that people need to know HOW. And, by pushing > what can be built on the client with bigger projects and more source, > an answer has become more important. > > So my answer to #0 is: > > It's difficult to test, package, debug, log, and document large jQuery > applications. > It's difficult to maintain, separate concerns, have consistent > development patterns, and provide re-usability of large jQuery > applications with developers of mixed skill levels. > > On > > "But I think it's both silly and foolish to assume that the only > solution to the problem of complexity is to hit it with the > MVC/Classical inheritance stick. " > > They are always many ways of solving problems. And, I think it's > critical to have a broad discussion on how to enable maintainable code > with an eye toward reuse. But, in my opinion, it's unfair to dismiss > MVC/Inheritance as a 'stick' because they are such commonly used > patterns. They are commonly used, I would argue, because they are > successful. They work not necessarily because they are a good fit, > but a new developer can understand them easily. By the time they > reach the skill level of the people who read a jQuery Development > newsgroup, they will be able to pick their own patterns. > > Finally, John I can't thank you enough for not dismissing me > outright. It speaks to your character to listen to someone not > involved with jQuery propose an entirely new branch. I am but a mere > pebble thrower. After
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
John, Thanks for your reply! You are absolutely right that we need to discuss which problems are difficult to solve. Is it safe to say that you agree that jQuery says very little about how to : - package and minimize multiple flies - document - test - dependency management - log errors / debugging tools ? Often developers are forced to pick from many completing plugins or 3rd party libraries. Similar to jQuery.UI this 'jQuery Enterprise' would provide a standard set of tools and come in a single integrated package. I think it's fair to say that this could bolster JS development just as much as an Accordion or Datepicker. On to separating concerns and providing reuse, It's very possible to separate concerns with jQuery/Prototype, or any other library, server or clientside. However, a good 'framework' forces that upon developers (but lets them escape it if necessary) in one standard way. The issue is that the developer has far too many choices. Consider the case of building a todo widget that connects to some backend service. Where do I put the files? What should I name the files? How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? Where should I be connecting to the service? How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). How can I create HTML in a readable manner? Giving this problem and jQuery to a novice developer will not result in similar code twice. If you want to enable broad code sharing, all these questions should have an answer. The jQuery/JMVC project I am consulting on now has about 300 files. If there is functionality I need to modify, I know, almost w/o exception where it has to be and how it is built. Getting to this point isn't a matter of documentation on jQuery's part. If you have to document it to get people to use it, people won't do it. You have to force people to do things a specific way (hence why generators became part of JMVC). In Scalable jQuery, you noted: # That the vast majority of what everyone does is directly related to the DOM. # That for the rare cases in which a pure-JavaScript structure is required, the plain JavaScript language is sufficient for meeting most needs. In my opinion, it is not rare on large projects. Much more logic goes into if a button is visible or can be clicked than into creating it and attaching an event. It's exactly because jQuery has done such an amazing job at solving IF we can build anything that people need to know HOW. And, by pushing what can be built on the client with bigger projects and more source, an answer has become more important. So my answer to #0 is: It's difficult to test, package, debug, log, and document large jQuery applications. It's difficult to maintain, separate concerns, have consistent development patterns, and provide re-usability of large jQuery applications with developers of mixed skill levels. On "But I think it's both silly and foolish to assume that the only solution to the problem of complexity is to hit it with the MVC/Classical inheritance stick. " They are always many ways of solving problems. And, I think it's critical to have a broad discussion on how to enable maintainable code with an eye toward reuse. But, in my opinion, it's unfair to dismiss MVC/Inheritance as a 'stick' because they are such commonly used patterns. They are commonly used, I would argue, because they are successful. They work not necessarily because they are a good fit, but a new developer can understand them easily. By the time they reach the skill level of the people who read a jQuery Development newsgroup, they will be able to pick their own patterns. Finally, John I can't thank you enough for not dismissing me outright. It speaks to your character to listen to someone not involved with jQuery propose an entirely new branch. I am but a mere pebble thrower. After exploring jQuery's core, I'm convinced that it provides the most elegant wrapping of the dom. After using JMVC on a number of large project, I'm very confident that it comes close to solving some #0's issues very well. My hope is that I can help jQuery solve them just as elegantly as it does the DOM. On Feb 24, 12:36 pm, John Resig wrote: > > Point well made and understood. > > > Perhaps what we're looking for here can be achieved without the > > wholesale adoption of an MVC framework. Perhaps the UI/widget > > framework can do a lot of the visual controller stuff anyway, allowing > > people to create abstract 'objects' (without full OOP) for controlling > > visual elements. Obviously DOM manipulation provides us with a view > > component, and people are free to create templating systems or > > whatever else they like on top of that. The real area where progress > > can be made, imo, is in data handling. That means, for example, being > > able to define a 'model' with certain field
[jquery-dev] A Modest Proposal: jQuery Enterprise
jQuery community, Amazing work. I can't believe how fast jQuery has developed into the best bottom-up JS library. 1.4 looks great. But as jQuery expands to include things like lazy loading, it might be time for a sister project that provides important, but less commonly needed functionality in a standard and organized way. Essentially, I would like to start a new branch of jQuery, akin to jQuery UI, that provides a standard set of tools and 'classes' that enable the development of more complex applications (by no means, does jQuery Enterprise has to be the name, just the first thing I came up with). The project COULD include: - A 'standard' way of organizing files - Compression - Documentation - Testing - Code generators - Scaffolding for easily connecting to services - Command line plug-in installation and dependency management. - A powerful class system (based off Resig's class) Obviously, these are all features of my project - JavaScriptMVC. But, I am more than willing to sacrifice the name/leadership/everything for the ability to explore these ideas with the jQuery community. Furthermore, it seems all JavaScriptMVC users use it with jQuery anyway! If you are questioning if these features are necessary, they are! I've worked on some very large projects with hundreds of custom JS files and multiple developers. At some point, developers need a repeatable way of building their applications and separating concerns. JavaScriptMVC provides that to a few lucky souls. I'd like to help jQuery provide that to everyone. It will also will help keep jQuery's core small and applicable to as many projects as possible. Here's my rough plan: 1. Get your blessing and support. Blessing being SVN access to a new branch. Support being interest and involvement from a few contributors. 2. Engage top jQuery contributors and users on application development best practices. I've slowly been interviewing some JS luminaries: http://javascriptmvc.com/blog/?cat=36. 3. Build it. I have already started to convert JavaScriptMVC to depend on jQuery (it's in JMVC's trunk). With support, this will take less than a month. That being said, I'm going to skip to step #2: jQuery community, What would you like to see in the jQuery "Framework"? How do you organize your applications? What sucks about testing, compression, documentation, etc? I can't wait to work for you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Event delegation
So, I've started the process of converting to jQuery. But, I think
there is a snag. I noticed that you can't cancel events. Is this on
the horizon? In JMVC, I collect all the elements that respond to the
event through delegation and order them. I dispatch each callback,
but if the event's "kill" function is called, it will not dispatch to
any other events.
I've found this ability necessary in many projects.
Also, will it be possible to delegate from other elements?
$(myelement).live("a.delete")
This is important once you start to get multiple instances of the same
widget on the page.
Thanks!
On Dec 24 2008, 7:28 am, "Dan G. Switzer, II"
wrote:
> Justin,
>
> > I listen for click instead of change. I check if it is on a SELECT
> > element. If it is, I check to see if its value has changed after each
> > click. I don't think using capture instead of bubbling will help.
>
> Just be aware that you're also need to then check for keypress as
> well--for those who are using the keyboard for data entry.
>
> -Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Event delegation
Change in IE: I listen for click instead of change. I check if it is on a SELECT element. If it is, I check to see if its value has changed after each click. I don't think using capture instead of bubbling will help. Change in webkit Listen for change, but I think it is called even if someone doesn't change the element. In this case I just check if the value has changed. Submit in IE listen for return keypress in text inputs and clicks on submit buttons. I'm going to hopefully play with this over the holidays. Does live call back delegated functions in the same order that bubbling happens? Is it possible to 'kill' live events w/o killing traditional events? It's great to see this in a mainstream library! I'm so impressed with jQuery. On Dec 22, 8:59 pm, Elijah Insua wrote: > Thank you, I just moved cross country and have been really busy. > Apparently I missed these > > Sent from my iPhone > > On Dec 22, 2008, at 9:54 PM, "Richard D. Worth" > wrote: > > > > > On Mon, Dec 22, 2008 at 6:48 PM, Elijah Insua > > wrote: > > > This list? I must be blind. My appologies > > > Here are some related threads: > > > Someone has Safari 2 ? > >http://groups.google.com/group/jquery-dev/browse_thread/thread/6a4bf8... > > > Status of jQuery with Safari 2.0.4? > >http://groups.google.com/group/jquery-dev/browse_thread/thread/9bc7ad... > > > Removal of jQuery.Browser usage > >http://groups.google.com/group/jquery-dev/browse_thread/thread/10a028... > > > - Richard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Event delegation
jQuery developers, I've heard that event delegation is being added to many of the big JS libraries, including jQuery. It has been a major component of JavaScriptMVC. For JavaScriptMVC's next version, I'm considering using jQuery by default and replacing any redundant functionality with jQuery or its plugins. For this to happen, I'd like to help with JavaScriptMVC's code if necessary. How far along is this effort? Have you already figured out the special edge cases -> submit/change in IE, change in webkit? Please let me know if I can help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
