On Dec 21, 2005, at 1:07 PM, Dennis Allison wrote:
Sorry if I appeared unresponsive--the fact that we use frames is
secret. I suppose that it would be helpful to make up soem
features for ongoing threads like this one.
It was a secret to me (again, perhaps because of my inability to keep
a thought in my head for more than an hour, for better or worse) or I
honestly I wouldn't have asked again. Just answering the questions
as they're asked would really, really be the best tact here, because
configurations change, code changes, and so on. What was gospel a
month ago might not be the case now. So it's important to just
answer the questions even if it seems utterly redundant to do so.
Again, I'm not chiding you here, I realize this is hard stuff, but I
need you to *help me help you* to get this put to bed.
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
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.
Yep.. particularly if you see a conflict only in requests that
directly follow a request for the frameset URL. If that's the case,
unless people constantly reload the frameset, you should be OK.
I did not know that XMLHttp interactions were asynchronous but
Most browsers can make multiple simultaneous requests so I'd
XMLHttp would just grab a connection and go and that multiple requests
can be in progress simultaneously.
After going and reading the docs for at least one implementation of
XMLHttpRequest, I think you're right. There are some asynchronous
things going on here. So I take it back. ;-)
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
some cautious experimentation and testing.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -