 |
|
|
| View previous topic :: View next topic |
| Author |
Message |
TESP
Joined: 30 Apr 2008 Posts: 3
|
Posted: Wed Apr 30, 2008 7:22 pm Passing data between frames after one frame loaded by Perl |
|
|
|
I'm looking for a solution;
In developing a site using frames, passing data from different html pages in frameset works unless a page is created by a Perl script.
example method to pass data is simply :
used in LEFT by javascript "top.right.document.rightformname.mydata1.value=1;"
and used in RIGHT by javascript "top.left.document.leftformname.mydata2.value=2;"
Other methods may us IDs, etc... not a problem.
HOWEVER,
if frameset has framename=LEFT src=left.htm
and framenameright=RIGHT src=right.htm
the passing of data between pages works.
if framename=LEFT src=left.pl and the Perl script writes(prints) the exact same html code as the static page, the passing of data with right.htm will not work.
Something is broken when the page is generated or loaded by a script rather than just opening a static page.
I can't find any reference info to explain why.
Help anyone? |
|
kanenas

Joined: 14 Dec 2004 Posts: 191
|
Posted: Fri May 02, 2008 8:39 am Re: Passing data between frames after one frame loaded by Pe |
|
|
|
Are you offering?
Don't ask pointless questions. It may seem petty and nit-picky, but learning how to ask questions the smart way is extremely important: it helps others understand what you want and it helps you understand your problem.
| TESP wrote: |
if framename=LEFT src=left.pl and the Perl script writes(prints) the exact same html code as the static page, the passing of data with right.htm will not work.
|
I hope you're sure the script produces the same page, because we have no way of knowing. Did you access the script URI in a browser, save the source and compare with the static page? Once you've done that, please post a minimal test case, including a pared-down version of your script. |
|
TESP
Joined: 30 Apr 2008 Posts: 3
|
Posted: Fri May 02, 2008 9:26 am example re: Frames problem |
|
|
|
Please be kind, I'm trying to solve a real problem.
The functional HTML page source was copied into
a Perl script sub routine such that it prints it verbatum. This is well understood and hasn't been a concern;
###
sub Printapage {
print "Content-type: text/html\n\n";
print <<EOP1;
<html><head>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<TITLE>frame 1 page</TITLE>
</HEAD>
<BODY>
<form name="datum" method=post action="http//blahblah.com/blah/blah.pl">
<input type=hidden name="item1" value="123">
<input type=hidden name="item2" value="456">
</form></body></html>
EOP1
}
###
within another frame, frame2, a javavscript grabs
, on an event, the values of item1 & item2 using the DOM.
ex.
document.TESTFORM.INPUT1.value=parent.frame1.document.datum.item1.value;
This works fine when html pages are initially loaded into the frames, however the DOM seems broken if frame1 loads as referenced a Perl script to write the page instead of a static page.
I read a snippet of info at MS that Windows XP SP1 to SP2 upgrade affect the "cache" in IE such that frames may loose their identity (this being a security measure). Rather than blaming MS for their obvious stupidity in many things, I thought someone may inderstand this and have a work-around.
Thanx, |
|
TESP
Joined: 30 Apr 2008 Posts: 3
|
Posted: Fri May 02, 2008 11:32 am Frame data passing resolved, kinda. |
|
|
|
The resultant discovery is;
IF the calling webpage is resident on a PC
and it loads some frames with local PC(client) pages
and others from the server, the FRAMES lose their ID
or the local versus server pages cannot find the frame ID.
I've experimented numerous times and the upshot is;
all pages in frames must all come from same source
(server or local) else the passing of data between frames (or windows) is prevented.
I suspect that IE appends to the ID the location the page was got from.
I haven't found a distinct reference anywhere, but
this may be useful info for others looking to make
combined interfaces that are both local and from the server.
TESP |
|
kanenas

Joined: 14 Dec 2004 Posts: 191
|
Posted: Fri May 02, 2008 6:29 pm load order; same-origin policy |
|
|
|
| TESP wrote: |
| Please be kind, I'm trying to solve a real problem. |
Sorry if I'm gruff. Very few help-seekers bother to give enough information, and few seem to perform enough research on their own. You did, and found the root of the problem (well, there's potentially another, but I'll get to that in a moment), and for that I applaud you.
Another potential gotcha is frame load order. If a script in one page tries to read the form values from another page before the second page has loaded, the form objects will be undefined and the read will fail. The fact that one page is output from a script means a slight delay which will increase the probability of occurence. You may or may not be seeing this affect in your setup. One solution to this is to have load handlers in each frame; each handler can:
- attempt to call a function (defined in only one of the documents, perhaps the parent; no need to reproduce the function in all pages) which performs initialization. The frame that loads last is the one that successfully calls the function.
-OR-
- call a function defined in the parent that registers the frame as having loaded (incrementing a counter is an easy way of implementing this). Once all frames have loaded, call the initialization function. This technique may be vulnerable to a race condition depending on implementation.
As for the IE security implementation, it's designed to prevent cross domain vulnerabilities. Just changing the access path ("append [the location the page was from] to the ID", as you put it) won't cut it. IE checks objects that have an associated domain (e.g. windows and documents) and compare that with the domain of the current script. I don't know the particulars, but it's something like that. Mozilla browsers also implement a same origin policy and support document.domain, as does Safari and most [all?] modern browsers. |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|
|