On Dec 21, 2005, at 11:38 AM, Dennis Allison wrote:


You asked about frames a while back and I responded in the affirmative. I am sure I mentioned that we use frames and framesets and explained that we use a bit of Javascript to manage loading individual frames rather than
loading the entire frameset whenever possible.

Eek. Sorry, I don't remember this. Context is hard to keep over the course of several weeks/months, of course. And my brain is going with my age. I don't mean to be a nag (really, I understand this is hard), but I asked two emails ago "do you use frames?" and you didn't answer that question directly in your response at all; only by way of teasing it out of you by asking if it was an IFRAME in a followup was the fact that this app is a frame-based one re-revealed to me. In general, it would be very helpful if you could answer the questions that are asked when they're asked even if they reveal the fact that I'm a doddering old man and can't remember things from moment to moment, Otherwise it's difficult (and honestly a bit frustrating) to try to help you.

In any case, typically the problem with frames only reveals itself when the entire frameset is loaded or the body of one frame causes the other frames to load. Your javascript may not be helping here... it could be hurting. For example, if a user reloads the "main" frame (say as a result of a POST request) and by doing so, during its re- rendering, it causes two other frames to refresh themselves due to an inline script function in the body of the main frame, that's the moral equivalent of reloading the frameset entirely. You have a tiny bit more control, e.g. maybe you could set a Javscript timer to reload the other frames in a "staggered" way where you reload one, then the other after a certain number of seconds. But otherwise it's the same problem. Hard to know what's going on there.

  Still, your point about
the multiple threads due to the requests from individual frames when a
frameset gets rendered is a valid one and one I have not given the weight
it deserves.

Issues around multiple threads and concurrency is going to be more and
more of a problem as we move to smarter clients and AJAX-like

"Smart clients" perhaps. But Ajax is supposed to allow you to do interesting things *without* reloading the page, and because (to my knowledge) no current Javascript implementation can make a request asynchronously, so you can only make one request at a time from within a given browser document. So using Ajax shouldn't cause *more* conflicts; it should cause fewer. Unless of course your Ajax calls emanate from different frames (different DOM "documents"). Then you're back in the same boat (depending on the Javascript implementation, I suppose). It's really a problem with frames (or more generally, multiple documents at the same time) rather than with Ajax.

It looks like there are several small things I can do to improve the
present system's conflict rate, but, absent some major structural changes, I won't be able to drive them to O(zero). Fortunately, while the level of
conflicts is high, they are infrequent relative to the number of hits
served, and most are resolved by the normal Zope conflict resolution

Well, that's good.  Does that mean I'm off the hook? ;-)

- C

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to