Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
By the time any markup is sent to the browser, the page will be finished rendering. Tapestry renders to a DOM then streams the DOM. Persistent fields will already be in the session, ready to be pulled out against a new page instance. On Mon, Apr 13, 2009 at 12:39 PM, Sergey Didenko wrote: > BTW, can't race conditions happen in the following case: > > A client without Javascript clicks on ActionLink before the page > finishes loading. > > ? > > This does not seem like it can be handled with the help of Javascript. > > On Sun, Apr 12, 2009 at 8:43 PM, Sergey Didenko > wrote: >> Does it race when "render" request uses an object from HttpSession and >> concurrent "action" request changes that object? >> >> If so, can't it be handled on server? I'm worring that the current >> client-based approach is going to be overcomplicated. >> >> On Sun, Apr 12, 2009 at 8:19 PM, Sergey Didenko >> wrote: >>> Sorry if I ask a silly question, i'm a newbie to Tapestry. >>> >>> You mention there were race conditions on slow connections. How were >>> they possible? >>> >>> If a page is rendering then it has already processed its handlers. So >>> when a browser gets a half of the page, all the related handlers >>> already finished their work, right? So what thing races with what? >>> >>> Regards, Sergey. >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
BTW, can't race conditions happen in the following case: A client without Javascript clicks on ActionLink before the page finishes loading. ? This does not seem like it can be handled with the help of Javascript. On Sun, Apr 12, 2009 at 8:43 PM, Sergey Didenko wrote: > Does it race when "render" request uses an object from HttpSession and > concurrent "action" request changes that object? > > If so, can't it be handled on server? I'm worring that the current > client-based approach is going to be overcomplicated. > > On Sun, Apr 12, 2009 at 8:19 PM, Sergey Didenko > wrote: >> Sorry if I ask a silly question, i'm a newbie to Tapestry. >> >> You mention there were race conditions on slow connections. How were >> they possible? >> >> If a page is rendering then it has already processed its handlers. So >> when a browser gets a half of the page, all the related handlers >> already finished their work, right? So what thing races with what? >> >> Regards, Sergey. >> > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Does it race when "render" request uses an object from HttpSession and concurrent "action" request changes that object? If so, can't it be handled on server? I'm worring that the current client-based approach is going to be overcomplicated. On Sun, Apr 12, 2009 at 8:19 PM, Sergey Didenko wrote: > Sorry if I ask a silly question, i'm a newbie to Tapestry. > > You mention there were race conditions on slow connections. How were > they possible? > > If a page is rendering then it has already processed its handlers. So > when a browser gets a half of the page, all the related handlers > already finished their work, right? So what thing races with what? > > Regards, Sergey. > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Sorry if I ask a silly question, i'm a newbie to Tapestry. You mention there were race conditions on slow connections. How were they possible? If a page is rendering then it has already processed its handlers. So when a browser gets a half of the page, all the related handlers already finished their work, right? So what thing races with what? Regards, Sergey. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
> Interesting; first I have to figure out how to accurately measure this > stuff (any ideas?), then we'll see if it makes a difference where the > page initialization logic actually goes. Maybe slow down the stream for the Javascript-library response. Are they returned by the asset-service? maybe the response can be slowed down to a couple of seconds per library. Add a simple piece of javascript that shows an alert-box. First put everything in the head. You should see the alert-box before anything renders. Then put eveything at the bottom of the page. If I'm not mistaken, you should see part of the page before the alert-box is shown. it is not an accurate measurement, but you can see clearly how different browsers handle things. regards, Onno > > > BTW I just checked in the first pass at these changes; it needs a > couple of tweaks but I'm pretty happy about how it's coming out. > > On Sat, Feb 28, 2009 at 10:30 AM, Onno Scheffers wrote: > > 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
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Em Fri, 27 Feb 2009 21:11:15 -0300, Howard Lewis Ship escreveu: Next, Ajax-y links and forms would have something like onclick="javascript:Tapestry.waitForPageLoad();" written into their HTML; this would be the logic that would raise the dialog if you clicked a link too early. That's nice, but don't forget about i18ning the "wait until the page finishes loading" message. ;) The cost would be: - Slightly uglier HTML output (use of the "javascript:" psuedo-scheme) Not really a problem, as only AJAXified links would be affected. - Increment increase in size of tapestry.js Why would it increase in size? By how much? The advantage is less confusion on the client side and server side between normal requests and Ajax partial render requests. The user can't "outrace" the application anymore. To me, this is more important than anything else. Howard, I'm no AJAX expert, but I think you're going in the right direction. ;) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Interesting; first I have to figure out how to accurately measure this stuff (any ideas?), then we'll see if it makes a difference where the page initialization logic actually goes. BTW I just checked in the first pass at these changes; it needs a couple of tweaks but I'm pretty happy about how it's coming out. On Sat, Feb 28, 2009 at 10:30 AM, Onno Scheffers wrote: > 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
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Em Sat, 28 Feb 2009 09:20:50 -0300, Joachim Van der Auwera escreveu: Looking at GWT pages for example they seem incredibly fast even with quite a lot of javascript. GWT is a very different beast. It generates a single JavaScript file with the whole application code and loads it up front. Example: Gmail. This approach can't be used in a framework like Tapestry, AFAIK. -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor Consultor, desenvolvedor e instrutor em Java http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
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
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
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 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
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
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
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
On Sat, Feb 28, 2009 at 3:34 AM, wrote: > Hello, > >> Further, on a page that loads slowly (one that has a large number of >> external scripts, is accessed via a slow-bandwidth pipe, or has a >> very complex layout), this means that JavaScript event handlers are >> not wired up until all JavaScript has been downloaded and parsed. The >> end result it that you can "outrace" Tapestry, click a link that >> should update a zone and get incorrect behavior or even a runtime >> exception. I actually see this when using Formo's time-tracking >> application from home through a slow pipe, exacerbated by HTTPS, where >> I get the error that "Block is not a valid response type". What should >> have been an Ajax request was processed instead as a traditional page >> render request, because the JavaScript was not ready. > > For this problem, doesn't the solution is server side ? > I mean, if the (non-XHR) request return a Block, it's an error in T5, and > all in all, there is no gracefull degradation. The server code should > always distinguish between XHR events and normal requests, and return > accordingly. Technically, that can be determined via the Request.isXHR() method. However, by then the horse has left the barn; in the "race" scenario, the user has clicked the link and initiated a full-page render even though the application developer had intended a partial render. The goal of the changes I'm outlining is to remove this "race" condition. > > Or perhaps it's a case of leaky abstraction : event handlers for normal > requests and for XHR one's might be actually different beasts (onXhrAction > / onAction ). > > I remember that there was several threads on that subject, especially this > one : http://markmail.org/thread/ho3nla6eciyupcah > > Francois > > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- 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
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Great ideas and great suggestions. Personally I see two problems. Many requirements documents (typically those for government related projects) require sites to be fully functional with javascript disabled. The proposal does not seem to address that at this moment. Ideally we should be able to detect whether the browser has javascript enabled and produce different content (not sure how this can be efficiently handled though). Any attempts to produce html which does not "need" javascript and tweaking on-load creates too much flicker (or at least, that was the case in my pages). The other problem that I had with tapestry (more precisely, that my users complained about) is the ability too click before the page is fully ready. The easy solution for this would be a "loading" overlay which is disabled as the very last javascript which is executed. This can almost be done at this moment, except that I know of no way to force a piece of javascript to be executed after tapestry's internal handling. This approach itself has some problems combined with the javascript disabled browsers of course. All in all, I *assume* a lot can be gained from better caching and/or javascript combining (as partly done in 5.1 and partly planned). Looking at GWT pages for example they seem incredibly fast even with quite a lot of javascript. It may also be useful to investigate how images can be combined for faster loading (as GWT is also planning to do). Just my 2c. Joachim Howard Lewis Ship wrote: I think it's well time to open a discussion about Tapestry 5 and JavaScript. I think Tapestry is getting a large number of things right, but also a small number of things wrong. This is not a discussion about jQuery vs. Prototype (that's a separate area), but more about the behavior of Tapestry JavaScript, within the constrains of the browser. In standard usage, the JavaScript for a page is collected together and moved to the bottom of the page: first a series of
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Hello, > Further, on a page that loads slowly (one that has a large number of > external scripts, is accessed via a slow-bandwidth pipe, or has a > very complex layout), this means that JavaScript event handlers are > not wired up until all JavaScript has been downloaded and parsed. The > end result it that you can "outrace" Tapestry, click a link that > should update a zone and get incorrect behavior or even a runtime > exception. I actually see this when using Formo's time-tracking > application from home through a slow pipe, exacerbated by HTTPS, where > I get the error that "Block is not a valid response type". What should > have been an Ajax request was processed instead as a traditional page > render request, because the JavaScript was not ready. For this problem, doesn't the solution is server side ? I mean, if the (non-XHR) request return a Block, it's an error in T5, and all in all, there is no gracefull degradation. The server code should always distinguish between XHR events and normal requests, and return accordingly. Or perhaps it's a case of leaky abstraction : event handlers for normal requests and for XHR one's might be actually different beasts (onXhrAction / onAction ). I remember that there was several threads on that subject, especially this one : http://markmail.org/thread/ho3nla6eciyupcah Francois - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
On 27-Feb-09, at 19:41 , Martin Strand wrote: On Sat, 28 Feb 2009 01:11:15 +0100, Howard Lewis Ship > wrote: This solution was weak, because there was no graceful degradation: clients without JavaScript would have a non-functioning application. Thus it was changed to render the href normally AND add an onclick event handler, which leads to the race conditions described above. I didn't quite understand this part. If a user clicks the link before its onclick handler has been added, wouldn't that result in the same behaviour as having javascript disabled? It would have, but with that solution, url's just had http://www.blah.com/context/page/# as the url to be clicked, which means that non-javascript clients, treating it as the same as if javascript was disabled, would try to access the in-page anchor "", which clearly doesn't exist. It would amount to a page refresh, and on some browsers not even that, since the browser would cache the page since you're not going anywhere. So for non-js or js-disabled clients, you need a real URL. christian. Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
Initialy, the onclick handler would be supplied as: update zone Thus, if you click it while the page is still loading, the waitForPageLoad() function will be invoked, which can raise the warning dialog. Once the page is fully loaded, the waitForPageLoad() handler is removed or deactivated, and additional onclick event handlers can be added via Prototype's Event.observe() function. The diffrerence between this and Tapestry 5.1.0.0 is that there's no inline onclick event handler; clicking the link while the scripts are loading results in a non-Ajax component event request (as opposed to an Ajax component event request via XmlHttpRequest). On Fri, Feb 27, 2009 at 4:41 PM, Martin Strand wrote: > On Sat, 28 Feb 2009 01:11:15 +0100, Howard Lewis Ship > wrote: > >> The >> end result it that you can "outrace" Tapestry, click a link that >> should update a zone and get incorrect behavior or even a runtime >> exception. I actually see this when using Formo's time-tracking >> application from home through a slow pipe, exacerbated by HTTPS, where >> I get the error that "Block is not a valid response type". What should >> have been an Ajax request was processed instead as a traditional page >> render request, because the JavaScript was not ready. >> >> An earlier version of Tapestry 5 approached this problem by disabling >> the link components when the zone parameter was in use; that is, the >> href parameter was written out a "#", so the only way the link would >> be active is via an attached onclick event handler. >> >> This solution was weak, because there was no graceful degradation: >> clients without JavaScript would have a non-functioning application. >> Thus it was changed to render the href normally AND add an onclick >> event handler, which leads to the race conditions described above. > > I didn't quite understand this part. If a user clicks the link before its > onclick handler has been added, wouldn't that result in the same behaviour as > having javascript disabled? > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- 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
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
On Sat, 28 Feb 2009 01:11:15 +0100, Howard Lewis Ship wrote: > The > end result it that you can "outrace" Tapestry, click a link that > should update a zone and get incorrect behavior or even a runtime > exception. I actually see this when using Formo's time-tracking > application from home through a slow pipe, exacerbated by HTTPS, where > I get the error that "Block is not a valid response type". What should > have been an Ajax request was processed instead as a traditional page > render request, because the JavaScript was not ready. > > An earlier version of Tapestry 5 approached this problem by disabling > the link components when the zone parameter was in use; that is, the > href parameter was written out a "#", so the only way the link would > be active is via an attached onclick event handler. > > This solution was weak, because there was no graceful degradation: > clients without JavaScript would have a non-functioning application. > Thus it was changed to render the href normally AND add an onclick > event handler, which leads to the race conditions described above. I didn't quite understand this part. If a user clicks the link before its onclick handler has been added, wouldn't that result in the same behaviour as having javascript disabled? - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [DISCUSS] JavaScript, Degradation, Page Load, Script Placement
I think some actual hard numbers would help with this. If an example page renders one way with js at the bottom, and another way with js at the top, these can be timed and compared. If real-world performance differences are at an acceptable minimum, then it's fine. But the fact that "top" is slower than "bottom" based on knowledge of how they render isn't enough, I think. Does anyone have a setup that could conveniently test page load/render times with these two configurations on an (otherwise) identical setup? Christian. On 27-Feb-09, at 19:11 , Howard Lewis Ship wrote: I think it's well time to open a discussion about Tapestry 5 and JavaScript. I think Tapestry is getting a large number of things right, but also a small number of things wrong. This is not a discussion about jQuery vs. Prototype (that's a separate area), but more about the behavior of Tapestry JavaScript, within the constrains of the browser. In standard usage, the JavaScript for a page is collected together and moved to the bottom of the page: first a series of
