Insert , Defer and Is there a better way?

[phegaro]

Hi all,
This might be a more generic browser/javascript questions than a
prototype specific quesiton but i thought it would better to ask here
because you all tend to really understand javascript and browsers in a
ton of detail. So here goes.

If i execute the following code:

HTML:

<div id="area"></div>

Javascript:

$('area').insert({bottom: "<div id="inserted"></div>"});

var count = 0;
var f = function() {
if ($('inserted') == null) {
console.log("not there");
count++;
if (count > 50) {
$('area'.insert({bottom: "<div id="inserted"></
div>"});
count = 0;
}
f.defer();
} else {
console.log("there");
}
};

f();


Result:

Most of the time it just shows:

>> there

but some of the time it does this

>> not there
>> not there
>> not there
>> there

I am assuming because the insert is something that is queued and the
browser then inserts the nodes into the DOM in its next event loop. I
know that webkit is a single threaded so this makes sense that
sometimes its not there and then it gets there, so really i guess i
have to wait till its there before i can do the "next thing" on that
inserted node. What about firefox and IE? Are they all single threaded
in the same way? What happens in Chrome?

Sometimes i see the following happen also which is really concerning
to me:

>> not there
>> not there
>> ... 50 times
>> not there
>> there

It happens every so often on webkit (mac os) and on iPhone webkit and
i can reproduce it pretty easily. I have built something simple that
will do this but all this seems a little crazy to me because when i
look at others code they dont even take this into account. They never
way for DOM elements to show up when inserting HTML text into a DOM
element.

Any answers/suggestions would be super helpful.

Kiran

[T.J. Crowder]

Hi Kiran,

It sounds like you've already put together a minimalist test case,
would you post it (e.g., to Pastie[1] or similar)? I haven't run into
a situation where a single defer wasn't sufficient, but I also haven't
tested extensively on Mac OS.

Cheers,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com

[phegaro]

HI T.J,
I'm sorry but are you asking for more than what is above? I can
write a simple page that puts together the HTML and JS listed above.
Is that what you want?

Kiran

[Matt Foster]

Hey Kiran,


Function.defer is simply delegating the functions execution to
Function.delay which in the end delegates it to a wrapper of
window.setTimeout.
By using defer it enforces the timeout to be a value of 0.01 which is
just enough to hiccup the browser's procedural processing.

If your application relies on this element to be inserted, avoid the
defer and you'll be sure the content is loaded after execution of
insert.

--

http://positionabsolute.net

[Matt Foster]

In taking a second look at your code...

Are you using the F function recursively to wait for the DOM to be
loaded and your "area" element to be available?

you can use many other approaches...

Prototype

$(document).observe("dom:loaded", function()...);

Traditional

window.onload = function()...

By executing your code in those methods, you can be sure that DOM
elements are loaded and ready for manipulation via Javascript.

[phegaro]

This is not during DOM load but post dom load where i am trying to
insert more dom elements into the tree that i am seeing things not
always load.

> > On Nov 2, 7:41 pm,phegaro<pheg...@gmail.com> wrote:
>
> > > HI T.J,
> > >   I'm sorry but are you asking for more than what is above? I can
> > > write a simple page that puts together the HTML and JS listed above.
> > > Is that what you want?
>
> > > Kiran
>
> > > On Oct 30, 2:22 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
> > > > Hi Kiran,
>
> > > > It sounds like you've already put together a minimalist test case,
> > > > would you post it (e.g., to Pastie[1] or similar)?  I haven't run into
> > > > a situation where a single defer wasn't sufficient, but I also haven't
> > > > tested extensively on Mac OS.
>
> > > > Cheers,
> > > > --
> > > > T.J. Crowder
> > > > Independent Software Consultant
> > > > tj / crowder software / comwww.crowdersoftware.com
>

[T.J. Crowder]

Hi,

> I'm sorry but are you asking for more than what is above? I can
> write a simple page that puts together the HTML and JS listed above.

Yes, there are a lot of details not included in that post, which may
be relevant. There are lots of good reasons to do a complete, stand-
alone test case, not least that it eliminates that problem (of missing
details). _Your_ doing it (rather than someone who isn't seeing the
problem) ensures that you create a test case that replicates the
behavior. Separately, when I'm seeing behavior that doesn't quite make
sense to me, when I do a separate isolated test case, I frequently
find that I did something _slightly_ wrong in the original. And if I
don't find that, I have something useful I can post here. :-)

So yes, I'd suggest doing that. FWIW, there's a starter page here:
http://proto-scripty.wikidot.com/self-contained-test-page

-- T.J.

[phegaro]

Hi T.J.,
I tried out creating a unit test case for this and doing stuff on
page load and i cant seem to reproduce this on Safari on the desktop
anymore. Its odd because i think it might have to do with timing and
how long the browser takes to render the content into the DOM but i
can reproduce in a simple unit test. I'll check that this unit test
works on iPhone and give you an update.

Thanks

Kiran