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
sergey.dide...@gmail.com wrote:
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
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
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
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
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
On Sat, Feb 28, 2009 at 3:34 AM, farm...@linagora.com 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
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
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
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
Em Sat, 28 Feb 2009 09:20:50 -0300, Joachim Van der Auwera
joac...@progs.be 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
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
Em Fri, 27 Feb 2009 21:11:15 -0300, Howard Lewis Ship hls...@gmail.com
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.
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
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
On Sat, 28 Feb 2009 01:11:15 +0100, Howard Lewis Ship hls...@gmail.com 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
Initialy, the onclick handler would be supplied as:
a href=mpage.mycomponent
onclick=javascript:Tapestry.waitForPageLoad();update zone/a
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
On 27-Feb-09, at 19:41 , Martin Strand wrote:
On Sat, 28 Feb 2009 01:11:15 +0100, Howard Lewis Ship hls...@gmail.com
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
18 matches
Mail list logo
