<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Dojo.addOnLoad vs. window and body onload</title>
	<atom:link href="http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/feed" rel="self" type="application/rss+xml" />
	<link>http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload</link>
	<description></description>
	<lastBuildDate>Thu, 01 Jun 2017 18:51:00 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Kaleb Walton</title>
		<link>http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/comment-page-1#comment-2970</link>
		<dc:creator>Kaleb Walton</dc:creator>
		<pubDate>Fri, 26 Jan 2007 02:21:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/#comment-2970</guid>
		<description>I&#039;ve become a pretty strong proponent of YUI and YUI-EXT. Since Dojo is contributed by so many individuals it&#039;s challenging for them to maintain consistency across their widgets and API. If you&#039;re comparing and contrasting some of the frameworks out there you may find one of my recent  &lt;a href=&quot;http://toserveman.kalebwalton.com/articles/2007/01/19/dojo-vs-yui-yui-ext-vs-prototype-scriptaculous-vs-mochikit-vs-jquery-part-1&quot; rel=&quot;nofollow&quot;&gt;blog posts&lt;/a&gt; of interest.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve become a pretty strong proponent of YUI and YUI-EXT. Since Dojo is contributed by so many individuals it&#8217;s challenging for them to maintain consistency across their widgets and API. If you&#8217;re comparing and contrasting some of the frameworks out there you may find one of my recent  <a href="http://toserveman.kalebwalton.com/articles/2007/01/19/dojo-vs-yui-yui-ext-vs-prototype-scriptaculous-vs-mochikit-vs-jquery-part-1" rel="nofollow">blog posts</a> of interest.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roland</title>
		<link>http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/comment-page-1#comment-184</link>
		<dc:creator>Roland</dc:creator>
		<pubDate>Fri, 04 Aug 2006 22:26:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/#comment-184</guid>
		<description>I agree with Brian. I&#039;ve built quite some large, rich client experience applications using the browser and javascript since 2000, and I&#039;m used to building stuff from scratch. 

I used to build everything myself because existing libraries were really just to invasisve or not flexible enough. Lately I&#039;ve been looking for alternatives and I checked out YUI and Dojo. 

Although YUI looks promising and has good documentation, it just lacks a lot of functionality I need, and it just is not flexible enough. 

Dojo on the other hand really seems very promising - the one thing that&#039;s missing badly IMO is the documentation. But that&#039;s growing rapidly, and i&#039;m actually already confident enough the indeed make the choice to embrace Dojo, and put up with the onload stuff.

Note however that the migration path from &lt;body onload=&quot;func()&quot;&gt; to dojo is really a nobrainer, (dojo.addOnLoad(func);). It should not take much effort to convert.

Actually, most people that build pages with javascript widgets will probably&#039;ve looked for a solution to initialize all their stuff without breaking the other initialization code - this is about as good as it gets, and Im thankful for dojo to offer a solution that works and remains extensible.

Cheers, 

Roland</description>
		<content:encoded><![CDATA[<p>I agree with Brian. I&#8217;ve built quite some large, rich client experience applications using the browser and javascript since 2000, and I&#8217;m used to building stuff from scratch. </p>
<p>I used to build everything myself because existing libraries were really just to invasisve or not flexible enough. Lately I&#8217;ve been looking for alternatives and I checked out YUI and Dojo. </p>
<p>Although YUI looks promising and has good documentation, it just lacks a lot of functionality I need, and it just is not flexible enough. </p>
<p>Dojo on the other hand really seems very promising &#8211; the one thing that&#8217;s missing badly IMO is the documentation. But that&#8217;s growing rapidly, and i&#8217;m actually already confident enough the indeed make the choice to embrace Dojo, and put up with the onload stuff.</p>
<p>Note however that the migration path from &lt;body onload=&#8221;func()&#8221;&gt; to dojo is really a nobrainer, (dojo.addOnLoad(func);). It should not take much effort to convert.</p>
<p>Actually, most people that build pages with javascript widgets will probably&#8217;ve looked for a solution to initialize all their stuff without breaking the other initialization code &#8211; this is about as good as it gets, and Im thankful for dojo to offer a solution that works and remains extensible.</p>
<p>Cheers, </p>
<p>Roland</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: brian</title>
		<link>http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/comment-page-1#comment-173</link>
		<dc:creator>brian</dc:creator>
		<pubDate>Tue, 01 Aug 2006 15:15:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/#comment-173</guid>
		<description>It&#039;s true to some degree that in order to move to a library like Dojo that you need to sort of &quot;accept it&quot;.  The good news is that the only real conflict that Dojo has (that I have come across so far) is with the onload where it is initialized.

There are some other projects out there that have &quot;LifeWith*&quot; sites like &lt;a href=&quot;http://www.lifewithqmail.org&quot; rel=&quot;nofollow&quot;&gt;Life With Qmail&lt;/a&gt; and &lt;a href=&quot;http://www.lifewithdjbdns.org&quot; rel=&quot;nofollow&quot;&gt;Life With DJBDNS&lt;/a&gt;.  I think Dojo would benefit from a similar site or even PHP-style &lt;a href=&quot;http://www.php.net/manual/en/&quot; rel=&quot;nofollow&quot;&gt;annotated documentation&lt;/a&gt;.

The amount of things that Dojo can do for you is really incredible.  Every time I am thinking about &quot;how should I do this?&quot;, I run a search through the source or Google and sure enough, Dojo has something sweet already baked in like dojo.style.getOuterHeight() for retrieving the combined height of an element or dojo.lfx.highlight() to highlight and fade an element on screen.  

There hasn&#039;t really been a comprehensive library like Dojo before (that I&#039;m aware of) so it takes some time in order to get accustomed to fully leveraging it.

So, no, I don&#039;t think that you need to know too much.  So long as you avoid the onload hijacking, the rest of it kind of falls into place.  I am only sprinkling Dojo around my existing application but you do, in my opinion, need to adjust your thinking into embracing it to really make gains.</description>
		<content:encoded><![CDATA[<p>It&#8217;s true to some degree that in order to move to a library like Dojo that you need to sort of &#8220;accept it&#8221;.  The good news is that the only real conflict that Dojo has (that I have come across so far) is with the onload where it is initialized.</p>
<p>There are some other projects out there that have &#8220;LifeWith*&#8221; sites like <a href="http://www.lifewithqmail.org" rel="nofollow">Life With Qmail</a> and <a href="http://www.lifewithdjbdns.org" rel="nofollow">Life With DJBDNS</a>.  I think Dojo would benefit from a similar site or even PHP-style <a href="http://www.php.net/manual/en/" rel="nofollow">annotated documentation</a>.</p>
<p>The amount of things that Dojo can do for you is really incredible.  Every time I am thinking about &#8220;how should I do this?&#8221;, I run a search through the source or Google and sure enough, Dojo has something sweet already baked in like dojo.style.getOuterHeight() for retrieving the combined height of an element or dojo.lfx.highlight() to highlight and fade an element on screen.  </p>
<p>There hasn&#8217;t really been a comprehensive library like Dojo before (that I&#8217;m aware of) so it takes some time in order to get accustomed to fully leveraging it.</p>
<p>So, no, I don&#8217;t think that you need to know too much.  So long as you avoid the onload hijacking, the rest of it kind of falls into place.  I am only sprinkling Dojo around my existing application but you do, in my opinion, need to adjust your thinking into embracing it to really make gains.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nathan Dintenfass</title>
		<link>http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/comment-page-1#comment-168</link>
		<dc:creator>Nathan Dintenfass</dc:creator>
		<pubDate>Sun, 30 Jul 2006 23:09:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.ghidinelli.com/2006/07/30/dojoaddonload-vs-window-and-body-onload/#comment-168</guid>
		<description>Is it just me, or do I hear a lot about battling javascript libraries of late?  Seems like to do truly interesting things various libraries perform gymnastics of one kind or another, and there really isn&#039;t a good way to deal with conflicts.  &quot;Hijacking&quot; the onload event for the body is probably really &quot;good&quot; for dojo internals to make things automagical, but it&#039;s not like having body onload events is some obscure thing for a web page to do -- thus, to use dojo you could be in a world of hurt if you have lots of page-level-customized body onloads.  Perhaps more importantly, what about the hapless developer who inherits your code and doesn&#039;t understand the various nuances -- in this case it seems you&#039;d have to have a pretty deep understanding of what is going on to debug why adding a seemingly innocent body onload is suddenly breaking lots of stuff.  Or, am I not seeing the big picture here?</description>
		<content:encoded><![CDATA[<p>Is it just me, or do I hear a lot about battling javascript libraries of late?  Seems like to do truly interesting things various libraries perform gymnastics of one kind or another, and there really isn&#8217;t a good way to deal with conflicts.  &#8220;Hijacking&#8221; the onload event for the body is probably really &#8220;good&#8221; for dojo internals to make things automagical, but it&#8217;s not like having body onload events is some obscure thing for a web page to do &#8212; thus, to use dojo you could be in a world of hurt if you have lots of page-level-customized body onloads.  Perhaps more importantly, what about the hapless developer who inherits your code and doesn&#8217;t understand the various nuances &#8212; in this case it seems you&#8217;d have to have a pretty deep understanding of what is going on to debug why adding a seemingly innocent body onload is suddenly breaking lots of stuff.  Or, am I not seeing the big picture here?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
