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,
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 "rende
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 th
> 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? mayb
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,
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
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.
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 immedia
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
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 quic
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 JavaScri
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
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 res
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
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 a
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 throu
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
18 matches
Mail list logo
