I must admit that I haven't played around and tested it myself. It's mostly theory:
Everything in the head is loaded and/or executed before the page continues loading. Therefore any Javascript-block in the head is executed immediately. In the case of prototype that means the event is bound immediately and theoretically it can be called earlier since the libraries are already loaded as well. When the Javascript is at the bottom, the different <script> tags are handled in the order they appear (since they may depend on one another). So reading of the page may stop while waiting for the resources to come in. Large parts of the page may already be displayed then, allowing the user to click on links and buttons. So even though the event that was being acted upon was dom:loaded, it pretty much acted as a page-loaded event since the final resources to be loaded are the javascript-includes at the bottom of the page. Initialization code cannot be run without those resources being loaded and this happens while the browser is already showing the content it has. regards, Onno On Sat, Feb 28, 2009 at 5:21 PM, Howard Lewis Ship <hls...@gmail.com> wrote: > So you think there's a difference between having the handler for the > document "dom:loaded" event at the bottom of the page vs. the top? > > > On Sat, Feb 28, 2009 at 7:25 AM, Onno Scheffers <o...@piraya.nl> wrote: > > I do like the fact that Javascript will move back into the head with this > > solution. It's pretty much 'the way of internet'. Everyone knows how to > use > > it and almost all Javascript examples show it that way. Moving the > > Javascript-includes to the bottom made some things more difficult; you > > cannot quickly mockup a page using inline onclick-attributes for example, > > since the libraries you depend on may not have been loaded yet. > > > > I think it was an optimization step that was forced onto the user and > > impacted the way (s)he worked. I had to put in quite some effort to get > > pages working in Tapestry again that were sent to me by web-designers. > That > > is, until it was possible to make the location of the Javascript > > configurable again. > > > > I'm not very happy with any popups or loading-messages being forced upon > me > > though. There are still plenty of non-AJAX applications that work great > > without the entire page needing to be loaded, especially if you setup > your > > pages to work without Javascript. > > > > Also, when the javascript-includes are inside the head, so can be the > > Javascript initialization code. > > This means you can execute the initialization code directly after the > _DOM_ > > was loaded. When the scripts are at the bottom you have to wait until the > > _page_ (including all resources) is loaded because you depend on the > > javascript libraries being available. > > When using the dom-loaded event instead of the page-loaded event, it > becomes > > much harder for a user to out-race Tapestry. On a slow connection, the > > hold-up is usually in resources, since only a couple of connections are > made > > at once by the browser. The DOM is usually loaded pretty quickly and the > > other resources have to fight for a connection. > > > > I must admit I currently use hardly any AJAX, mostly because it is very > hard > > to do in Tapestry. This is one area where Wicket is way ahead of Tapestry > 5: > > you get back the full state of the page when a component makes a callback > > from the client to the server and from the handler you simply return all > > components that require updating. Wickets handles the stuff for you on > the > > client. > > If you open a modal dialog for example, you can tell it to send callback > > when the dialog is opened, or moved, or closed etc. That way you can > program > > pretty much all of the behavior using Java on the server. > > > > In Tapestry things are much more complex with Zones and lots of custom > > Javascript. I think we can learn some things here from Wicket. > > > > > > regards, > > > > Onno > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
