On Wed, 21 Dec 2005, Chris McDonough wrote: > On Dec 21, 2005, at 11:38 AM, Dennis Allison wrote: > > > > > Chris, > > > > 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.
Sorry if I appeared unresponsive--the fact that we use frames is hardly a secret. I suppose that it would be helpful to make up soem summary of features for ongoing threads like this one. > > 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. By convention the primary content frame does not cause other frames to re-render but there are multiple implementors and creaping featurism which may have changed that. The navigation_box frame we have been discussion gets re-rendered on a navigation change (duh) and may initiate re-rendering of a tabs_frame. Except for the full frameset rendering, we are likely to be fairly conflict clean. I can look in the logs and tell... Might be interesting. > > 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 > > implementations. > > "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. I did not know that XMLHttp interactions were asynchronous but serialized. Most browsers can make multiple simultaneous requests so I'd assumed that XMLHttp would just grab a connection and go and that multiple requests can be in progress simultaneously. > > 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 > > mechanism. > > Well, that's good. Does that mean I'm off the hook? ;-) Not really off the hook as issues still remain and you are a valuable resource. :-) I need to spend some time thinking about the issues an do some cautious experimentation and testing. _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )