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.
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
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.
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? ;-)
- C
_______________________________________________
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 )
