> Actually, that idea ain't stupid a'tall, in one sense at least... I'm sure
> this is doable in JavaScript...
> You create a JavaScript function to generate a real long random
> number, or a
> UUID, and you then invoke this function with the <BODY OnLoad()... method.
> No, wait... that ain't gonna work if the user creates a new
> page... Or would
> it? I'm startin' to think it would work...
I had originally started down that line, but the
problem is that the UUID generated by Javascript
means nothing to the server. Regardless of what
happens, you get back a different UUID every time.
I had considered the idea of something like this:
<script language="javascript">
windowNumber = 0;
window.onload = getWindowNumber;
getWindowNumber() {
windowNumber++;
}
</script>
That doesn't work because the initialization code is
called when you spawn a new window.
BUT -- I think I have an idea!
Suppose we generate a random number and pass it as
a form field with each page. When the onload event is
triggered, we would check to see if that number is
different from what it was last time. (I guess that
means setting a cookie in javascript to
remember what the last value was.) If it hasn't
changed, we know the page wasn't refreshed, and
therefore we must have a new window.
For example:
--
Page is opened, with Random ID: 1111, Window A
Memory cookie records the following:
A=1111
New window is spawned from Window A.
Javascript sees that the ID matches what's
in the cookie. This must be a new window. JS
will assign the window a unique name and
generate a random number for it (1234).
MemoryCookie: A=1111&B=1234
The user does something in A. CF recognizes
that this is window A and calls the WDDX packet
it created for Window A. In the response, it
returns a new random number for A (5544). As
the page is loaded, JS recognizes that
5544<>1234, so this is the same window. The
new number is written to the memory cookie.
MemoryCookie: A=5544&B=1234
The user does something in window B. CF has
no record of Window B, so it creates a new
packet for it. Then it gives B a new
number (2001), and so on.
MemoryCookie: A=5544&B=2001
--
It would probably make more sense to use an
incrementor than a random number, but
using random numbers made the explanation
simpler.
The one problem this doesn't solve is
transactions.
To use the classic example, if this is an
ATM application, and window A shows $1000,
when window B is spawned, it will also
show $1000. If you deduct $500 in window
A, window B will still show $1000.
I guess if necessary, you could use this
technique to prevent spawned windows from
being used (by closing them or displaying
an error message). Or maybe the way your
app works, you won't have these problems.
What do you think?
Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
