[jQuery] Object vs. Array looping
Hi all,In the .css method an array is created by: d = [Top,Bottom,Right,Left];Then it is looped through using object looping:for ( var i in d ) {
This probably isn't a problem for most people, but we have added functions to the Array prototype, so whenever the .css method is used it dumps the text of all those functions into the CSS and bloats the code considerably. I made the following patch and tested it. It seems to work fine:
Index: jquery.js===--- jquery.js (revision 575)+++ jquery.js (working copy)@@ -1472,7 +1472,7 @@ if ( p == height || p == width ) {
var old = {}, oHeight, oWidth, d = [Top,Bottom,Right,Left];- for ( var i in d ) {+ for ( var i = 0; i d.length; i++ ) {
old[padding + d[i]] = 0;old[border + d[i] + Width] = 0; }Thanks,Brendan
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Performance question
I have a somewhat related observation. I have discovered that when selecting by ID, the context parameter does not matter. In other words, these two statements are functionally equivalent:$(#myId);
and$(#myId, myContext);It's as if when the id selector is passed then the $ method just uses a document.getElementById. Besides the fact that this may produce unexpected results, it also means that you should be careful when using IDs to try to gain performance. Because if the size of your markup is large then this
$(#myId, myContext);may actually be slower then this$(.myClass, myContext);I have definitely seen performance gains by using the second one over the first.Brendan
On 10/9/06, Raziel Alvarez [EMAIL PROTECTED] wrote:
Thanks for all your responses. I actually do all the things that you mentioned: reusing the jQ object, chaining, setting a context, etc. Actually it would be helpful to have some performance
analysis on the different kinds of queries, such as searching by ID, by element, class name, attribute, xpath queries, context-delimited, etc., because even though it's somewhat straightforward to know that a search by ID is faster than searching by class name, it'd be interesting (and useful)to know by how much.
On 10/7/06, Matt Stith [EMAIL PROTECTED]
wrote:
yes, that would help quite a bit, since jquery would only need to look once.On 10/7/06, Jacky
[EMAIL PROTECTED] wrote: Would caching the jQuery object a help too? Sometimes you just can't
keep the chain. e.g. var jqObj = $(#abc);
On 10/8/06, Karl Swedberg [EMAIL PROTECTED] wrote: On Oct 7, 2006, at 3:39 PM, George Adamson wrote:
An easy performance booster is to use the second param in $() to set a
context for the search. Eg: $(DIV.myClass, myParentElement). Perhaps this is what you meant when you mentioned 'getting a parent element' ?
Chaining methods is helpful so you can avoid re-querying. If you need to put other code in betwen method calls then reusing the same JQuery object by
putting it into a variable beforehand is worth while to save requerying. If you're going to do several queries inside the same parent element (s) then
a combination of the above will be a big help. Those sound like good suggestions to me, though I'm no expert. Something I try to keep in mind is the relative speed of different
types of queries. This has been mentioned on the list before, but in case you didn't see it, references to IDs are fastest, followed by elements, and then classes. At least, that's how I've understood
previous discussions of the topic. So: a.$('#my-id') is faster than $('div#my-id'), and b. $('div.my-class') is faster than $('.my-class') Hop that helps.
Karl ___ Karl Swedberg www.englishrules.com
www.learningjquery.com___ jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/ -- Best Regards, Jacky
網絡暴民 http://jacky.seezone.net
___ jQuery mailing list discuss@jquery.com
http://jquery.com/discuss/
___jQuery mailing listdiscuss@jquery.com
http://jquery.com/discuss/
___jQuery mailing listdiscuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] Bug in Droppables and Code Revert
There is a bug in Droppables right now (I have the latest code, and the bug is also present on the Droppables demo page on interface.eyecon.ro), where the tolerance : pointer isn't working. I debugged a little and jQuery.iDrop.pointer is using the value of jQuery.iDrag.dragged.dragCfg.pointer.x and jQuery.iDrag.dragged.dragCfg.pointer.y whereas jQuery.iDrop.fit and intersect are both using jQuery.iDrag.dragged.dragCfg.nx and ny. I changed pointer to use nx and ny in my code and that seems to have fixed it. Just wanted to point that out in case anyone else was seeing this. Also, and I guess this is directed at Stefan. Bryan and I have requested to revert the change made so that draggables could be dropped in Sortables because the new version isn't quite working properly (you can go back to that discussion thread to see the problems we had). I was just wondering if that's going to happen, or if some other change will be made. As it is right now, I can't really work on my project. Thanks,Brendan ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Interface: draggables, droppables, and sortables
Bryan,What you're trying to do is exactly what I want as well. The approach I had was to make the container Droppable and Sortable. But like I said in my original email you can't do this because Sortable hijacks the Droppable functionality. I was just looking for a way to use both on the same container. If there wasn't a good workaround, then I was thinking something like Sortable having its own separate functionality, instead of overwriting the Droppable functionality that you may have already added. So it would still use Droppables, but in its own space, if that makes any sense. Because I don't want it to overwrite the onDrop callback, for example. I was using onDrop to create new elements, just as Bryan described. I see that in Stefan's example he is using the onStop callbacks of Draggable to create the element. I didn't use this originally because it doesn't give you the container that the Draggable was dropped in, but onDrop does. And I need the container. And speaking of the demo, I agree with Bryan that the demo isn't perfect. I also would like to use ghosting to drag from my pallette, but that doesn't really work now. And I also agree that Droppables is obsolete. Which is not good, because like I said I need to use onDrop, not onStop. Anyway, the reason I wrote the original email was to1. Point out that since Sortables hijacks any previously defined Droppables, the two cannot be used together in the same container.2. See if there was a workaround for it. I wasn't necessarily asking for a code change (unless there was no workable solution). So if there is a workaround (without the new change), I'd love to hear it. Bryan, maybe you have some ideas? And if so, maybe we should go back to the original functionality.Thanks,Brendan On 9/21/06, bbuchs [EMAIL PROTECTED] wrote: Sorry, but I just had another tought...The demos I initially provided were simplified - my end goal is not to justmove an DOM element from one side of the page to another. What I was tryingto accomplish was that the dropping would initiate a function that creates a brand new DOM element that is quite different from the one that had beendragged. I suppose I should have made that clearer from the start. - bryanbbuchs wrote: Stefan, I hate to harp on this, but the more I work with your new draggables automatically become sortables function, the less i like it. While the demo you created certainly works, I have a couple of issues with it. First, from a usability perspective, I would want to turn ghosting on for the items in the pallette; doing that currently breaks the demo. Right now, if a user drags an item in the pallette, it appears as if it's being removed, not cloned. I'm sure this will be fixed eventually. Secondly, your code change more or less makes droppables obsolete, and unless your objective is to do exactly what Brendan had set out to do, it's unintuitive logic. If I have something I want to drag, I would also have something to drop it on. Converting it into a sortable object is not the most likely use case scenario. Instead, wouldn't the SortableAddItem function be the more logical solution? I don't want to give the impression that I'm not grateful for your contributions - I AM! I just think that you reacted so quickly to one person's feature request and may not have considered what it meant in the bigger picture for everyone else. bbuchs wrote: Brendan, Thanks for doing a good job explaining what I was trying to - the jQuery.iSort.helper.get bug. I would hope that this can be fixed. I can see a situation where I might want to have a list on a page that isn't a sortable until a user initiates that action (click here to sort this list). If I have any other draggables on the page, I would get the error described below. Your tip about the accepts paramater also works great. I still strongly disagree that draggables should automatically become part of a sortable if it's dropped in one, but at least I can work around it. The only remaining issue I have is that the draggablesortable feature breaks the ghosting functionality for the draggable. In my demo, the right-side draggables are essentially a palette of items. The user should be dragging out a copy of each item, not the item itself. Again, that can be accounted for if the ghosting bug is fixed. Thanks guys! - Bryan Brendan O'Brien wrote: Hi, I'm responding to a few things in this post. First, I took a look at Bryan's example pages.The problem you see on the second page (where isortables.js has been included, but no Sortables have been declared) that throws the error |jQuery.iSort.helper.get is not a function|; I've had this problem too even before the Sep. 11 patch.The problem is that when isortables has been included, then draggables attempts to execute the line: jQuery.iSort.helper.get(0).style.display = 'none' when dragging over a droppable to hide the sortable helper.But since you never called Sortables this variable is just the boolean value false.It
[jQuery] Sortables conflicting with Droppables
Hi all,I have a situation where I want to make a container both Droppable and Sortable at the same time. The use case is, you drag a button into the Droppable container, and when you do so the onDrop callback creates an HTML node and inserts it into the container. I also want those objects to be Sortable, so that I can reorder them after I have dropped them into the container. But if I make the container Droppable first and then Sortable, then it doesn't quite work. When I initialize the containers as Sortable, it first makes the accept elements Draggable, and then tries to make the container Droppable. But, since I have already made it Droppable, the Sortable code sees this and skips it. Thus the Droppable still works, and the accept elements are draggable, but I can't drop them anywhere, so they always just revert to where they originated from. If I do it the other way around, make the container Sortable and then Droppable then the opposite is true. The elements are sortable, but nothing happens when I drop something in the container.I was wondering if anyone else has seen this problem, and if so if they have a workaround or solution. I tried adding an onDrop as a Sortables configuration parameter, and then appending the method that is passed in after the default onDrop that Sortables adds to the container. That was moderately successful, but then I ran into more issues, because it still tried to sort. I added a cancelling mechanism, but there were more issues with that. You can see where this is going... Any suggestions on this issue would be greatly appreciated.Thanks,Brendan O'Brien ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
