/
fluid-work IRC Logs-2008-08-13

fluid-work IRC Logs-2008-08-13

Aug 13, 2008

[07:15:43 EDT(-0400)] * ajt (n=alex@75.103.40.106) has joined #fluid-work
[07:15:50 EDT(-0400)] <ajt> Howdy
[07:59:42 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:25:58 EDT(-0400)] * jhung (n=Administ@H236.C194.cci.switchworks.net) has joined #fluid-work
[09:52:25 EDT(-0400)] <Bosmon> Hello, ajt
[09:52:46 EDT(-0400)] <ajt> Bosmon: How's it going?
[09:52:53 EDT(-0400)] <Bosmon> It is tolerable
[10:03:55 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[10:05:18 EDT(-0400)] * Topic is 'it's wednesday, topic is hump day' set by jessm on 2008-08-13 10:05:18 EDT(-0400)
[10:10:53 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:12:11 EDT(-0400)] <Bosmon> "Hump Day"
[10:12:21 EDT(-0400)] <Bosmon> Hump Day, Dump Day?
[10:13:29 EDT(-0400)] <anastasiac> yes, hump day
[10:14:10 EDT(-0400)] <anastasiac> you know this term, no?
[10:14:20 EDT(-0400)] <Bosmon> It seems I do now...
[10:15:35 EDT(-0400)] <Bosmon> http://www.urbandictionary.com/define.php?term=hump+day&amp;defid=1401714#1401714
[10:16:08 EDT(-0400)] <jacobfarber> you use the urban dictionary?!
[10:16:46 EDT(-0400)] <Bosmon> For non-native slang, yes
[10:16:48 EDT(-0400)] <Bosmon>
[10:17:09 EDT(-0400)] <jacobfarber> is that where you got bolus? http://www.urbandictionary.com/define.php?term=bolus
[10:17:26 EDT(-0400)] <Bosmon> ..
[10:17:35 EDT(-0400)] <Bosmon> I would tend to use the OED for things that are real words
[10:17:46 EDT(-0400)] <jacobfarber>
[10:19:20 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:40:22 EDT(-0400)] * jessm rarely uses "real words"
[11:04:15 EDT(-0400)] <Bosmon> "hump" is a real word....
[11:05:37 EDT(-0400)] * jessm rarely uses "real word" combinations
[11:05:58 EDT(-0400)] <jessm> e.g. process documents
[11:13:22 EDT(-0400)] <Bosmon> I want to see your process documents!
[11:13:25 EDT(-0400)] <Bosmon> Time flies like a banana!
[11:24:00 EDT(-0400)] <Bosmon> jacobfarber: Any ideas on our drag handle issue?
[11:26:04 EDT(-0400)] <jacobfarber> i was discussing this with anastatia this morning.... I couldnt think of another way that would solve the cpu crisi
[11:26:45 EDT(-0400)] <jacobfarber> could you send me lin e# where the code starts to be problematic?
[11:27:01 EDT(-0400)] <Bosmon> Well, I have accelerated the lookup for now
[11:27:12 EDT(-0400)] <Bosmon> I think we are now more interested in "quality of implementation" issues
[11:27:17 EDT(-0400)] <Bosmon> The two JIRAs that I quoted yesterday
[11:27:28 EDT(-0400)] <Bosmon> i can't see we can solve either of them without going to a CSS-based approach
[11:27:59 EDT(-0400)] <Bosmon> And, possibly, having to bite the IE6 bullet and physically grunge into the markup and insert an <a if necessary....
[11:28:19 EDT(-0400)] <Bosmon> Do you think that is conceivable?
[11:28:34 EDT(-0400)] <jacobfarber> i would shy away from the <A> solution for now.... it might bring about some serious headaches....
[11:28:43 EDT(-0400)] <jacobfarber> but I agree
[11:31:15 EDT(-0400)] <jacobfarber> can I call you on skype
[11:31:17 EDT(-0400)] <jacobfarber> ?
[11:32:03 EDT(-0400)] <jacobfarber> Bosmon: sorry, should have addressed that more accurately....can I call you on skype?
[11:41:03 EDT(-0400)] <jacobfarber> Bosmon: just taking another peek at the uPortal demo.... something strange
[11:41:52 EDT(-0400)] <Bosmon> OK, yes sorry
[11:41:55 EDT(-0400)] <Bosmon> I don't get notifications on this thing
[11:42:01 EDT(-0400)] <Bosmon> Best to AIM me individually
[11:42:04 EDT(-0400)] <jacobfarber> ok
[11:42:21 EDT(-0400)] <Bosmon> Although we will be standing up in a few minutes now
[11:42:25 EDT(-0400)] <Bosmon> Maybe we can chat afterwards
[11:42:32 EDT(-0400)] <jacobfarber> ok
[11:43:04 EDT(-0400)] <Bosmon> A general question about the reorderer - can anyone recall how we decided on our current avatar strategy?
[11:43:16 EDT(-0400)] <Bosmon> That is, our "default policy" of duplicating the entire DOM material for the draggable object
[11:43:34 EDT(-0400)] <Bosmon> It is quite expensive, although I have speeded it up somewhat...
[11:43:47 EDT(-0400)] <Bosmon> I am noticing looking at DnD managers "out in the wild", there are two main approaches
[11:44:01 EDT(-0400)] <Bosmon> i) The "NetVibes" et. al approach which is simply to use the DOM node itself as its avatar
[11:44:19 EDT(-0400)] <Bosmon> ii) "cheap avatars" made of just, for example, a title bar in the right colour and an empty square
[11:44:34 EDT(-0400)] <Bosmon> Either of these would allow us to get good performance on drag start...
[11:45:55 EDT(-0400)] <Bosmon> Also - do we have any written explanation anywhere of where we require ids on elements and where we do not?
[11:46:11 EDT(-0400)] <Bosmon> It appears the two "simple" LayoutManagers (List and Grid) will function without ids, whereas ModuleLayout will not
[11:59:49 EDT(-0400)] <jacobfarber> Bosmon: out of curiosity, have you looked at DOM DocumentFragments for speeding up avatar manipulation? http://ejohn.org/blog/dom-documentfragments/
[12:01:20 EDT(-0400)] <Bosmon> That is something worth knowing about...
[12:01:33 EDT(-0400)] <jacobfarber> the speed increase is very noticeable
[12:01:48 EDT(-0400)] <Bosmon> Although I don't think it could help from where the code stands right now since the remaining overhead is just basically clone + iteration
[12:01:49 EDT(-0400)] <jacobfarber> could make for a good vehicle for any of our DOM related adjusting
[12:01:58 EDT(-0400)] <jacobfarber> oh
[12:02:05 EDT(-0400)] <anastasiac> Bosmon, regarding how we came up with the strategy of cloning the DOM element, you may want to email the list about this one. I suspect it was a design decision, and perhaps the designers might recall better
[12:02:12 EDT(-0400)] <Bosmon> Ah
[12:02:34 EDT(-0400)] <anastasiac> I do recall that discussion for the uPortal example specifically, but I'm not sure about it in general
[12:02:38 EDT(-0400)] <anastasiac> i.e. as a default
[12:02:51 EDT(-0400)] <jacobfarber> have we looked into how ExtJS works in this regard?
[12:03:02 EDT(-0400)] <jacobfarber> with their "live dragging" ?
[12:03:07 EDT(-0400)] <Bosmon> Yes
[12:03:11 EDT(-0400)] <Bosmon> They just drag the node itself
[12:03:13 EDT(-0400)] <Bosmon> A la netvibes
[12:03:42 EDT(-0400)] <Bosmon> Right now our avatar creator is down to about 30ms
[12:03:57 EDT(-0400)] <Bosmon> 50% of that is spent simply in iteration
[12:03:58 EDT(-0400)] <jacobfarber> in which browser? FF?
[12:04:04 EDT(-0400)] <Bosmon> FF2 yes
[12:04:11 EDT(-0400)] <anastasiac> yes, I'm pretty sure our designers wanted the original to remain in place while dragging was ongoing
[12:04:17 EDT(-0400)] <Bosmon> I tend to like to use it since it is particularly slow
[12:04:19 EDT(-0400)] <anastasiac> I don't recall the reason fo rit
[12:04:24 EDT(-0400)] <Bosmon> Yes, but we didn't actually give them that
[12:04:33 EDT(-0400)] <Bosmon> At the moment the original is replaced by an outline
[12:04:34 EDT(-0400)] <anastasiac> in the lightbox, we do
[12:04:34 EDT(-0400)] <Bosmon> And hidden
[12:04:37 EDT(-0400)] <Bosmon> Ah, I see
[12:05:02 EDT(-0400)] <anastasiac> in the reorderer in general, we do - the uPortal example is a custom special case, I think
[12:05:50 EDT(-0400)] <Bosmon> Avatar creation for the lightbox doesn't take any detectable time
[12:05:57 EDT(-0400)] <Bosmon> Less than a Windows clock tick...
[12:06:01 EDT(-0400)] <jacobfarber> Bosmon: are you thinking it would be faster to apply the dnd to the node itslef and not a clone of it?
[12:06:10 EDT(-0400)] <Bosmon> jacobfarber: yes
[12:06:20 EDT(-0400)] <Bosmon> it is what most other libraries seem to do
[12:06:35 EDT(-0400)] <Bosmon> Essentially some of them, like netvibes, seem to have a drag start time of close to zero
[12:06:40 EDT(-0400)] <anastasiac> Also, regarding your question "do we have any written explanation anywhere of where we require ids on elements and where we do not" my answer would be no, there is no explanation, and if there is such a requirement, we should document it, but we are trying to avoid such a requirement
[12:06:57 EDT(-0400)] <Bosmon> I mean, the "extra" 30ms is now not so threatening, but it will always be there
[12:07:17 EDT(-0400)] <Bosmon> anastasiac: Right now the ModuleLayout cannot function without ids not only on every cell, but also on every column
[12:07:17 EDT(-0400)] <jacobfarber> then what im wondering is why not do exactly that, and THEN re-inject the original content back in to the original spot...instead of the reverse
[12:07:45 EDT(-0400)] <anastasiac> right - I remember having that discussion about ids with jacobfarber...
[12:07:46 EDT(-0400)] <jacobfarber> giving you an immediate drag effect, without losing the content
[12:07:48 EDT(-0400)] <anastasiac> yes, it should be documented
[12:07:59 EDT(-0400)] <anastasiac> ideally, it should be avoided - the requirement should be removed
[12:08:09 EDT(-0400)] <anastasiac> but that's a much larger task
[12:08:38 EDT(-0400)] <Bosmon> jacobfarber: You mean, to defer creation of the "duplicate" content to a setTimeout?
[12:08:50 EDT(-0400)] <Bosmon> I am wondering which would appear more distracting
[12:09:02 EDT(-0400)] <jacobfarber> im not sure about the timeout...but switch the order of operations
[12:09:14 EDT(-0400)] <Bosmon> To have the dragging avatar "late", or to have the shadow image of the "left-behind" instance "late"
[12:09:33 EDT(-0400)] <jacobfarber> instead of clone then drag clone....drag original and then clone and inject back into original spot
[12:09:58 EDT(-0400)] <jacobfarber> or at least re-inject a placeholder of equivalent size
[12:10:06 EDT(-0400)] <jacobfarber> to maintain context
[12:10:06 EDT(-0400)] <Bosmon> Yes, but that couldn't actually give any greater responsiveness, unless we could defer some operations to occur outside the event handler
[12:10:38 EDT(-0400)] <jacobfarber> wouldnt you get an immediate reposne of "draggability" ?
[12:10:40 EDT(-0400)] <Bosmon> Actually personally I'm a little afraid of libraries that have apparently zero drag start overhead
[12:10:51 EDT(-0400)] <Bosmon> jacobfarber: Not if you didn't return from the event handler
[12:11:05 EDT(-0400)] <Bosmon> I mean, not if you didn't return from it instantly
[12:11:10 EDT(-0400)] <Bosmon> And leave some of your work "on the table"
[12:11:28 EDT(-0400)] <jacobfarber> using setTimeout of 0 or something like that?
[12:11:32 EDT(-0400)] <Bosmon> The greater part of our current start delays are elsewhere anyway, in the "computeOffsets" method
[12:11:40 EDT(-0400)] <jacobfarber> i see
[12:11:43 EDT(-0400)] <Bosmon> But I am still interested to see what we could shave off avatar creation
[12:12:20 EDT(-0400)] <Bosmon> Yes, avatar creation has shrunk from 125ms to 31ms in my change of last night
[12:12:24 EDT(-0400)] <Bosmon> Which "might" be acceptable
[12:12:42 EDT(-0400)] <Bosmon> But I think we need to aim for an overall budget of starting the operation within around 100ms
[12:12:54 EDT(-0400)] <Bosmon> So 31ms still represents a really appreciable chunk of that....
[12:13:08 EDT(-0400)] <jacobfarber> what exactly does the 31ms cover?
[12:13:19 EDT(-0400)] <jacobfarber> in terms of whats accomplished?
[12:13:49 EDT(-0400)] <Bosmon> We clone the markup, iterate over the DOM for it, destroy any "id" attributes we find, and set the state of any <input controls to "disabled"
[12:13:59 EDT(-0400)] <Bosmon> And then make a handful of CSS adjustments to the root node of the lulmp
[12:14:13 EDT(-0400)] <Bosmon> Around 10ms is burned doing the clone itself
[12:14:31 EDT(-0400)] <Bosmon> And then pretty much all of the remaining 20ms is just in the iteration - the actual manipulation is pretty minimal
[12:14:44 EDT(-0400)] <Bosmon> These portlets are pretty chunky and have on the order of hundreds of nodes in them
[12:14:53 EDT(-0400)] <Bosmon> So it takes a considerable time simply to scan them...
[12:15:27 EDT(-0400)] <jacobfarber> so thats where documentfragments might help
[12:15:38 EDT(-0400)] <Bosmon> Well, I'm not sure it would
[12:15:45 EDT(-0400)] <jacobfarber> iterating over the nodes while out of the normal visible DOM space
[12:15:55 EDT(-0400)] <Bosmon> Well... that might be faster
[12:15:57 EDT(-0400)] <jacobfarber> worht a shot
[12:16:05 EDT(-0400)] <Bosmon> but I think we are essentially still crossing the "native code barrier"
[12:16:16 EDT(-0400)] <Bosmon> I don't think there is any extra overhead in the iteration due to "visibility"
[12:16:26 EDT(-0400)] <Bosmon> Since what you manipulate in Javascript is a "frozen snapshot" in any case
[12:16:27 EDT(-0400)] <jacobfarber> i think your very close anyway....it doesnt sound like there is any huge bloat at that point
[12:16:47 EDT(-0400)] <jacobfarber> its not the "visibility" literally
[12:16:50 EDT(-0400)] <Bosmon> Yes, I think the best approach would be to investigate "whole node dragging" at some point
[12:17:10 EDT(-0400)] <jacobfarber> its the fact that there is very little the nodes can do when attached to a documentfragment
[12:17:14 EDT(-0400)] <jacobfarber> like no computedStyle
[12:17:22 EDT(-0400)] <jacobfarber> which takes off a fair bit of overhead
[12:17:27 EDT(-0400)] <Bosmon> Since for a start since we hide the original node in the Portlet reorderer, we get really no benefit from having to clone it
[12:17:28 EDT(-0400)] <Bosmon> Right
[12:17:33 EDT(-0400)] <Bosmon> There is a chance it may be faster
[12:18:00 EDT(-0400)] <jacobfarber> still....10ms....its not like thats a noticeable delay!
[12:18:02 EDT(-0400)] <Bosmon> But I think the main benefits in DocumentFragment would probably be in faster updates, rather than in faster traversals
[12:18:07 EDT(-0400)] <jacobfarber> oh
[12:18:48 EDT(-0400)] <jacobfarber> i would take a look at the article though, specifically the Append part
[12:19:00 EDT(-0400)] <Bosmon> Yes, I have been reading this
[12:19:07 EDT(-0400)] <Bosmon>
[12:19:41 EDT(-0400)] <Bosmon> OK, so lets unwind the stack a bit...
[12:19:52 EDT(-0400)] <Bosmon> So, we all seem agreed that we would prefer ModuleLayout to not require ids
[12:20:01 EDT(-0400)] <Bosmon> Although I wonder what it would use, in this case
[12:20:29 EDT(-0400)] <Bosmon> In theory, we could just keep a raw cache of structures involving DOM nodes somewhere
[12:20:35 EDT(-0400)] <Bosmon> But the potential for leaks seems worrying
[12:20:59 EDT(-0400)] <Bosmon> Alternatively we can forcibly write ids onto nodes we require to look up quickly if they don't have them
[12:21:04 EDT(-0400)] <Bosmon> That is equally, if not a bit more, worrying
[12:22:25 EDT(-0400)] <Bosmon> Basically, looking things up using jQuery is just too slow
[12:22:31 EDT(-0400)] <Bosmon> Especially for situations where we are inside mouse drag loops
[12:22:54 EDT(-0400)] <Bosmon> jQuery gives is nice lookups "in the other direction", that is, creating "surrogate keys" for a DOM node using jQuery.data
[12:23:00 EDT(-0400)] <Bosmon> but this doesn't help us to go the other way round
[12:23:09 EDT(-0400)] <Bosmon> SO, we need to make a choice between the two options
[12:23:12 EDT(-0400)] <Bosmon>
[12:23:25 EDT(-0400)] <Bosmon> i), a cache of raw DOM nodes, ii) manual injection of ids into the markup
[12:23:28 EDT(-0400)] <Bosmon> Which is it to be?
[12:25:20 EDT(-0400)] <jacobfarber> just curious: is the DOM cache going down a dangerous path of rigidity?
[12:25:32 EDT(-0400)] <Bosmon> Well, it would have a "refresh" method like everything else
[12:25:42 EDT(-0400)] <Bosmon> To be honest the Reorderer isn't yet even slightly flexible
[12:25:48 EDT(-0400)] <jacobfarber> like if you cache a node that would refresh itself...
[12:25:50 EDT(-0400)] <Bosmon> So the DOM cache represents at the moment no net loss
[12:25:56 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-46.LIPS.Berkeley.EDU) has joined #fluid-work
[12:25:58 EDT(-0400)] <jacobfarber>
[12:26:08 EDT(-0400)] <Bosmon> There is a global "refresh" method on the Reorderer now
[12:26:21 EDT(-0400)] <Bosmon> Which is intended to be a central point of call for people who have done things that structurally invalidates the markup
[12:26:38 EDT(-0400)] <Bosmon> But at the moment all it refreshes is the "fastLocate" cache in the DOM binder
[12:26:54 EDT(-0400)] <Bosmon> Unfortunately for many applications even "fastLocate" isn't fast enough
[12:27:13 EDT(-0400)] <jacobfarber> um, how fast are you hoping to get this thing??
[12:27:16 EDT(-0400)] <Bosmon> Well, it is sort of fast enough.... but it is not "detailed" enough
[12:27:20 EDT(-0400)] <Bosmon>
[12:27:34 EDT(-0400)] <Bosmon> fastLocate is actually adequate for the List and Grid reorderers
[12:27:47 EDT(-0400)] <Bosmon> But it isn't helpful enough for the Module reorderer
[12:28:03 EDT(-0400)] <jacobfarber> ***jacobfarber imagines Bosmon whipping poor little javascript - "faster faster!"
[12:28:04 EDT(-0400)] <Bosmon> THis doesn't just require to get a raw bunch of nodes, but actually to rapidly answer geometrical queries about them
[12:28:19 EDT(-0400)] <Bosmon> Javascript DOES need to be faster
[12:28:36 EDT(-0400)] <Bosmon> At the moment it uses the requirement that the nodes have Ids on them, and stores these ids in its structure
[12:28:40 EDT(-0400)] <Bosmon> Which is where we came in
[12:28:44 EDT(-0400)] <Bosmon> We are trying to demolish this requirement
[12:29:25 EDT(-0400)] <Bosmon> Now, my thinking is, whatever we do, should be via the golden intermediate of jQuery.data
[12:29:37 EDT(-0400)] <Bosmon> In one of two ways
[12:29:50 EDT(-0400)] <jacobfarber> to be honest, im not 100% sure why we couldnt use the reorderLayout api to identify columns and modules...
[12:30:05 EDT(-0400)] <jacobfarber> nice, simple selectors
[12:30:15 EDT(-0400)] <Bosmon> !!!!!
[12:30:26 EDT(-0400)] <Bosmon> Either i) store a reverse lookup of jQuery.data ids onto the raw DOM nodes somewhere, or ii) forcibly cram a new id related to the jQuery.data id onto the node
[12:30:42 EDT(-0400)] <Bosmon> You know how long it takes to run a selector?
[12:30:57 EDT(-0400)] <Bosmon> Anyway, yes
[12:30:58 EDT(-0400)] <jacobfarber> jQuery benchmarks are published on slickspeed
[12:31:04 EDT(-0400)] <Bosmon> Yes
[12:31:32 EDT(-0400)] <jacobfarber> speed <vs> flexibility
[12:31:34 EDT(-0400)] <Bosmon> I'm sure we could improve the "incoming" APi of reorderLayout
[12:31:55 EDT(-0400)] <Bosmon> But we need better runtime data structures and requirements...
[12:32:43 EDT(-0400)] <Bosmon> Personally I would choose option ii)
[12:32:53 EDT(-0400)] <Bosmon> But it does "on paper" violate one of our core religions on DOM obtrusiveness
[12:33:44 EDT(-0400)] <Bosmon> But I'm not sure helping someone to index something properly that they hadn't bothered to index really counts as an "obtrusion"
[12:37:55 EDT(-0400)] <Bosmon> jacobfarber: The comment thread on the DocumentFragment page is interesting
[12:38:02 EDT(-0400)] <Bosmon> Especially this observation:
[12:38:04 EDT(-0400)] <Bosmon> # In Firefox (v.1.5 and 2), when the fragment is appended to the main document, any script part of the final fragment's markup (for example, in the case of the Forms Designer any script contained in the template) will be executed. This may lead to scripts being executed twice. This behavious doesn't apply to IE 6/7.
[12:38:20 EDT(-0400)] <jacobfarber> ouch
[12:38:33 EDT(-0400)] <jacobfarber> are they sure thats not a bug?
[12:38:39 EDT(-0400)] <Bosmon> Hard to tell
[12:38:53 EDT(-0400)] <Bosmon> I'm not sure the W3C DOM has very much to say about script execution
[12:39:32 EDT(-0400)] <jacobfarber> didnt we work on this problem with that whole "document.writeLine()" thing?
[12:39:36 EDT(-0400)] <Bosmon> I was half-tempted to use DocumentFragments for implementing the "correct" DOM shuffle algorithm we need for the reorderer
[12:39:41 EDT(-0400)] <Bosmon> But now I think I had better not
[12:39:59 EDT(-0400)] <Bosmon> Some chaps in the thread claim that DFs are not notably different to any other kind of "detached element"...
[12:40:15 EDT(-0400)] <jacobfarber> so orphan nodes are faster?
[12:40:35 EDT(-0400)] <Bosmon> No, they say that if anything, DFs are faster
[12:40:45 EDT(-0400)] <Bosmon> But that comparing orphans with DFs there is much less difference
[12:40:52 EDT(-0400)] <Bosmon> Just a difference in the API semantic...
[12:41:23 EDT(-0400)] <Bosmon> About half of the respondents claim they perform the same
[12:42:19 EDT(-0400)] <Bosmon> jacobfarber: Have you had experience detaching some massive portion of the DOM, manipulating it and then putting it back in one event cycle?
[12:42:25 EDT(-0400)] <Bosmon> Does the browser tend to behave sensibly?
[12:43:34 EDT(-0400)] <jacobfarber> no, i've tried doing this with an ajax injection of sorts....IE6 hung until the node was completely rendered.. IE7 wasnt AS bad
[12:43:59 EDT(-0400)] <jacobfarber> its was a big chunk of elements though...a few hundred
[12:44:01 EDT(-0400)] <Bosmon> I mean, say you were doing a table sort
[12:44:10 EDT(-0400)] <jacobfarber> probably the same effect
[12:44:12 EDT(-0400)] <Bosmon> It would seem sensible, on the face of it, to detach the entire table
[12:44:17 EDT(-0400)] <Bosmon> Do the sort, then reattach it
[12:44:18 EDT(-0400)] <jacobfarber> yes
[12:44:30 EDT(-0400)] <jacobfarber> my thoughts exactly, but when you attach it
[12:44:34 EDT(-0400)] <jacobfarber> if its big enough
[12:44:41 EDT(-0400)] <Bosmon> You get a big burp?
[12:44:41 EDT(-0400)] <jacobfarber> it might hang ie6 for a second
[12:44:44 EDT(-0400)] <jacobfarber> yup
[12:44:49 EDT(-0400)] <jacobfarber> nothing....then splat
[12:44:52 EDT(-0400)] <Bosmon> Yes
[12:45:19 EDT(-0400)] <Bosmon> but presumably a shorter splat than if you had sat there writing O removeChild and appendChild statements in the same handler...
[12:45:54 EDT(-0400)] <jacobfarber> maybe even more so if you had that setTimeout thing to allow the browser to breathe a bit
[12:46:24 EDT(-0400)] <Bosmon> It would be interesting to compare the 3 methods
[12:46:39 EDT(-0400)] <Bosmon> Since the other option is to re-render the table, using the nascent "Fluid Renderer"
[12:47:45 EDT(-0400)] <Bosmon> And then blat it in in one go using "innerHTML"
[12:47:55 EDT(-0400)] <Bosmon> innerHTML actually seems surprisingly fast...
[12:48:03 EDT(-0400)] <Bosmon> Compared to making your hands grubby with heaps of nodes
[12:48:07 EDT(-0400)] <jacobfarber> its the fastes way so far....unfortunately
[12:48:59 EDT(-0400)] <Bosmon> Well, it is not so unfortunate if you have a renderer on your side
[12:49:17 EDT(-0400)] <Bosmon> Interestingly, to bring our discussion full circle, one of the most expensive parts of the renderer is in computing node IDs
[12:49:33 EDT(-0400)] <jacobfarber> just stripping them out?
[12:49:41 EDT(-0400)] <Bosmon> But at the moment it does this via the "full RSF" algorithm which does a lot of string concatenation
[12:50:10 EDT(-0400)] <Bosmon> A better option might be to just assign "any old unique" ids, of the sort I am proposing to do in ModuleLayout
[12:50:44 EDT(-0400)] <jacobfarber> what do you mean "any old unique" ?
[12:50:49 EDT(-0400)] <Bosmon> Well, you know
[12:50:53 EDT(-0400)] <Bosmon> Some short thing with a number
[12:50:59 EDT(-0400)] <jacobfarber> right
[12:51:10 EDT(-0400)] <Bosmon> My proposal is "fluid-id-"+jQuery.data(node)
[12:52:57 EDT(-0400)] <Bosmon> Where in Mike has Colin gone
[12:53:06 EDT(-0400)] <jacobfarber> hes on the phone I think
[12:53:09 EDT(-0400)] <ecochran> Bosmon: I was just going to suggest that you use the jQuery id from data
[12:53:09 EDT(-0400)] <Bosmon> I seem to remember he was one of the foremost objectors to "id forcing"....
[12:54:18 EDT(-0400)] <ecochran> Bosmon: could you reference the item using the jQuery id without assigning that id to an id selector?
[12:54:19 EDT(-0400)] <jacobfarber> Bosmon: couldnt we build something where we could ref. a node in a hash table, something like a mini JS BD?
[12:54:29 EDT(-0400)] <Bosmon> Yes, quite easily
[12:54:33 EDT(-0400)] <Bosmon> But that is route i)
[12:54:41 EDT(-0400)] <Bosmon> My worry is of DOM leaks...
[12:54:44 EDT(-0400)] <jacobfarber> oh
[12:55:02 EDT(-0400)] <ecochran> Bosmon: DOM leaks?
[12:55:22 EDT(-0400)] <Bosmon> Depending on where that structure is kept, we may be bitten by the "DOM cycle gc bug" in IE6 and alike...
[12:55:22 EDT(-0400)] <ecochran> and sorry, I missed all the options, I'm just jumping in to this conversation cold
[12:55:30 EDT(-0400)] <Bosmon> Which I'm still not convinced we fully understand...
[12:55:43 EDT(-0400)] <jacobfarber> do you have a link to the bug?
[12:55:51 EDT(-0400)] <Bosmon> I have read various blogs about it
[12:56:01 EDT(-0400)] <Bosmon> I vaguely remember Crockford's was the best explanation....
[12:56:01 EDT(-0400)] <ecochran> well, we've been promised that as long as we bind using jQuery that it is "taken care of" for us
[12:56:06 EDT(-0400)] <Bosmon> Right
[12:56:20 EDT(-0400)] <ecochran> do we believe it?
[12:56:30 EDT(-0400)] <Bosmon> But in keeping an independent data structure of DOM nodes, it seems we run the risk of breaking our promises
[12:56:42 EDT(-0400)] <Bosmon> But perhaps jQuery really does just "take care of that"
[12:56:56 EDT(-0400)] <Bosmon> Yes, perhaps the only evil is in the references that run the other way
[12:57:05 EDT(-0400)] <Bosmon> References back into the tree that are stored in event handlers &c
[12:58:32 EDT(-0400)] <Bosmon> http://javascript.crockford.com/memory/leak.html
[12:58:43 EDT(-0400)] <Justin_o> who fixed the safari dnd bug?
[12:59:31 EDT(-0400)] <Bosmon> OK, I need to go to dinner for a while
[13:02:13 EDT(-0400)] <Bosmon> Yes, the "separate cache" of jQuery id to DOM node data structure has the potential to be very slightly faster than the other way
[13:21:42 EDT(-0400)] <ecochran> very slightly faster are beginning to split hairs here?
[13:21:46 EDT(-0400)] <ecochran> enjoy your dinner!
[13:22:01 EDT(-0400)] <ecochran> are we beginning to split hairs here
[13:37:01 EDT(-0400)] * athena7 (n=athena7@adsl-99-149-83-32.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[13:39:19 EDT(-0400)] <athena7> hi folks - i've found some issues with javascript not working correctly in portlets when combined with the fluid reorderer
[13:39:45 EDT(-0400)] <athena7> in particular, it seems like things like the bookmarks portlet and jquery inline calendar don't work
[13:48:05 EDT(-0400)] <ecochran> athena7: jen, it looks like all the folks who could answer your question are currently offline. You might post something to fluid-work or check back in a little while when Antranig or Anastasia are back online
[13:48:24 EDT(-0400)] <athena7> sounds like a good plan, thanks
[13:48:27 EDT(-0400)] <ecochran> Antranig = Bosmon, Anastasia = anastasiac
[13:48:48 EDT(-0400)] <ecochran> I'd help but I'm not familiar enough with the code or bugs and would probably confuse things
[13:48:51 EDT(-0400)] <athena7> s'ok
[13:49:00 EDT(-0400)] <athena7> i didn't realize antranig wasn't really here
[13:49:47 EDT(-0400)] <ecochran> he just popped out for dinner
[13:51:58 EDT(-0400)] <athena7> ah right, it's late there
[14:00:54 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[14:02:11 EDT(-0400)] <athena7> ooh, it looks like upgrading from .4 to the trunk may have fixed things
[14:02:22 EDT(-0400)] <athena7> we shall see
[14:09:51 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[14:09:56 EDT(-0400)] <ecochran> athena7: great
[14:33:23 EDT(-0400)] <athena7> ok, problem persists, will look for relevant dev types later
[16:39:55 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[19:03:35 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[19:04:09 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work