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
