468,310 Members | 1,418 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,310 developers. It's quick & easy.

refering layer in new window

Hello NG,

I am using javascript to open a new window like this:

printpreview=window.open('printview.php','printpre v','width=600,height=600');

The new window has a layer called preview:

<div id="preview"></div>

I am now trying to write to that layer using innerHTML = "blah bla";

How do I refer to that layer?

Thanks,
Christian
Jul 23 '05 #1
6 1663
"news.versatel.de" wrote:
Hello NG,

I am using javascript to open a new window like this:

printpreview=window.open('printview.php','printpre v','width=600,height=600');

The new window has a layer called preview:

<div id="preview"></div>

I am now trying to write to that layer using innerHTML = "blah bla";

How do I refer to that layer?

Thanks,
Christian


It's a bad idea to do:

var newWindowReference = window.open(...);
newWindowReference.document.write(...); // or
newWindowReference.document.getElementById(...);

There is no guarantee that the new window is open, or has a valid document by the
time the code referring to it execute. So, for starters, printview.php should
have <body onload="if (opener && opener.callBack) opener.callBack();"> as a
minimum. Then, in the page that opened the new window, you can have:

window.newWindowReference = window.open(...);
function callBack() {
if (document.getElementById) {
var theDiv =
window.newWindowReference.document.getElementById( 'preview');
if (typeof theDiv.innerHTML == 'string') {
theDiv.innerHTML = 'some text';
}
}
}

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #2
DU
Grant Wagner wrote:
"news.versatel.de" wrote:

Hello NG,

I am using javascript to open a new window like this:

printpreview=window.open('printview.php','printp rev','width=600,height=600');

The new window has a layer called preview:

<div id="preview"></div>

I am now trying to write to that layer using innerHTML = "blah bla";

How do I refer to that layer?

Thanks,
Christian

It's a bad idea to do:

var newWindowReference = window.open(...);
newWindowReference.document.write(...); // or


Don't you have to open the document and close it? Like
newWindowReference.document.open();
newWindowReference.document.write(...);
newWindowReference.document.close();
" Closes a document stream opened by open() and forces rendering."
http://www.w3c.org/TR/2003/REC-DOM-L...ml#ID-98948567
There is a problem when not closing the document in Mozilla-based
browsers and possibly other browsers as well.
newWindowReference.document.getElementById(...);

There is no guarantee that the new window is open, or has a valid document by the
time the code referring to it execute. So, for starters, printview.php should
have <body onload="if (opener && opener.callBack) opener.callBack();"> as a
minimum. Then, in the page that opened the new window, you can have:

window.newWindowReference = window.open(...);
newWindowReference is already a type window (return value of the
window.open() call); so it is not needed to prefix it with window.
function callBack() {
if (document.getElementById) {
var theDiv =
window.newWindowReference.document.getElementById( 'preview');
if (typeof theDiv.innerHTML == 'string') {
The problem I see here (I might be wrong) is that *as written*, the
innerHTML value of that div id="preview" will be null: there is no
string when writing
<div id="preview"></div>.
Generally speaking, the structure
<div id="preview">&nbsp;</div>
is more manageable from a script perspective.
theDiv.innerHTML = 'some text';


Also possible is branching DOM 3 textContent and innerText and/or
childNodes[0].nodeValue assuming
<div id="preview">&nbsp;</div>

DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Mozilla 1.7.3 :)
Jul 23 '05 #3
>> function callBack() {
if (document.getElementById) {
var theDiv =
window.newWindowReference.document.getElementById( 'preview');


DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Mozilla 1.7.3 :)


Thanks very much, but I get an "object expected" error in the line
"if(document.getElementById)..." in the newly opened window. Any idea what
may cause this?

Christian
Jul 23 '05 #4
DU wrote:
It's a bad idea to do:

var newWindowReference = window.open(...);
newWindowReference.document.write(...); // or


Don't you have to open the document and close it? Like
newWindowReference.document.open();
newWindowReference.document.write(...);
newWindowReference.document.close();
" Closes a document stream opened by open() and forces rendering."
http://www.w3c.org/TR/2003/REC-DOM-L...ml#ID-98948567
There is a problem when not closing the document in Mozilla-based
browsers and possibly other browsers as well.


It's still a bad idea for the reason I gave. Attempting to do:

newWindowReference = window.open(...);
// newWindowReference.document may not exist yet!
newWindowReference.document.open();
newWindowReference.document.write(...);
newWindowReference.document.close();

will fail at least some of the time, in some browsers.

newWindowReference = window.open('javascript:opener.someString', ...);

is a better and more reliable way to do this. Of course, the reliability of any of this
depends on JavaScript being enabled, the implementation supporting window.open(), any
popup blocking mechanism the end-user may have and where and how the new window appears
(as a tab in a tabbed browser window?). But, even given all that, do you want to make
it even _more_ unreliable by attempting to access a not-yet-created document of the new
window?
window.newWindowReference = window.open(...);


newWindowReference is already a type window (return value of the
window.open() call); so it is not needed to prefix it with window.


I included it to indicate that newWindowReference is explicitly a member of the current
window. I prefer to do this rather than having variable assignments that may or may not
be "global" depending on whether it was declared with "var" somewhere earlier in the
same code block.
function callBack() {
if (document.getElementById) {
var theDiv =
window.newWindowReference.document.getElementById( 'preview');
if (typeof theDiv.innerHTML == 'string') {


The problem I see here (I might be wrong) is that *as written*, the
innerHTML value of that div id="preview" will be null: there is no
string when writing
<div id="preview"></div>.
Generally speaking, the structure
<div id="preview">&nbsp;</div>
is more manageable from a script perspective.


typeof theDiv.innerHTML will always be "string" if innerHTML is supported. In your
example (an empty <div>):

<body onload="test();">
<div id="preview"></div>.
<script type="text/javascript">
function test() {
var p = document.getElementById('preview');
alert('[' + p.innerHTML + '];' + typeof p.innerHTML);
}
</script>

IE 6, Mozilla 1.0.2, Mozilla 1.7.3, Firefox 1.0PR, Opera 7.54 show an empty string and
typeof "string". Although I will acknowledge that there may exist some user agents that
support the setting and retrieving of innerHTML, where an empty element returns null
and typeof "object".
theDiv.innerHTML = 'some text';


Also possible is branching DOM 3 textContent and innerText and/or
childNodes[0].nodeValue assuming
<div id="preview">&nbsp;</div>


The problem I have with the W3C standard is that constructing a node tree for even
mildly complex HTML is extremely tedious and fraught with peril. If you have a string
containing unknown HTML that is moderately to highly complex, innerHTML seems the way
to go. Hand the string to the browser, let it render it. Parsing it (probably badly)
and attempting to construct a node tree out of it is simply duplicating the effort
already put into writing the browser and is better left to the user agent (via
innerHTML). After all, it _knows_ how to do that, it had to do it for the entire page
in the first place.

On the other hand, if I am adding <form> elements or inserting additional fixed, known
content, I typically use the W3C methods.

I really wish innerHTML had been made part of the standard, considering it is probably
extremely easy to implement from the user agent developers' perspective.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #5
DU
Grant Wagner wrote:
DU wrote:

It's a bad idea to do:

var newWindowReference = window.open(...);
newWindowReference.document.write(...); // or
Don't you have to open the document and close it? Like
newWindowReference.document.open();
newWindowReference.document.write(...);
newWindowReference.document.close();
" Closes a document stream opened by open() and forces rendering."
http://www.w3c.org/TR/2003/REC-DOM-L...ml#ID-98948567
There is a problem when not closing the document in Mozilla-based
browsers and possibly other browsers as well.

It's still a bad idea for the reason I gave. Attempting to do:

newWindowReference = window.open(...);
// newWindowReference.document may not exist yet!


Yes, I agree with you on this. The window may have been created while
the document may not be loaded and referencible in the memory.
newWindowReference.document.open();
newWindowReference.document.write(...);
newWindowReference.document.close();

will fail at least some of the time, in some browsers.

I agree.
newWindowReference = window.open('javascript:opener.someString', ...);

is a better and more reliable way to do this. Of course, the reliability of any of this
depends on JavaScript being enabled, the implementation supporting window.open(), any
popup blocking mechanism the end-user may have and where and how the new window appears
(as a tab in a tabbed browser window?). But, even given all that, do you want to make
it even _more_ unreliable by attempting to access a not-yet-created document of the new
window?

No. Of course not. I was merely indicating that one need to open(), and
then close() the writing of the string into the document. When people
don't do that, the browsers (at least Mozilla-based browsers) are in a
state of perpetual downloading, expecting, waiting for the download to
stop: they are in a state of waiting.
window.newWindowReference = window.open(...);
newWindowReference is already a type window (return value of the
window.open() call); so it is not needed to prefix it with window.

I included it to indicate that newWindowReference is explicitly a member of the current
window.


Ok. So, this was for instructional purposes.

I prefer to do this rather than having variable assignments that may or
may not be "global" depending on whether it was declared with "var" somewhere earlier in the
same code block.

Ok.
function callBack() {
if (document.getElementById) {
var theDiv =
window.newWindowReference.document.getElementBy Id('preview');
if (typeof theDiv.innerHTML == 'string') {
The problem I see here (I might be wrong) is that *as written*, the
innerHTML value of that div id="preview" will be null: there is no
string when writing
<div id="preview"></div>.
Generally speaking, the structure
<div id="preview">&nbsp;</div>
is more manageable from a script perspective.

typeof theDiv.innerHTML will always be "string" if innerHTML is supported. In your
example (an empty <div>):

<body onload="test();">
<div id="preview"></div>.
<script type="text/javascript">
function test() {
var p = document.getElementById('preview');
alert('[' + p.innerHTML + '];' + typeof p.innerHTML);
}
</script>

IE 6, Mozilla 1.0.2, Mozilla 1.7.3, Firefox 1.0PR, Opera 7.54 show an empty string and
typeof "string". Although I will acknowledge that there may exist some user agents that
support the setting and retrieving of innerHTML, where an empty element returns null
and typeof "object".

theDiv.innerHTML = 'some text';


Also possible is branching DOM 3 textContent and innerText and/or
childNodes[0].nodeValue assuming
<div id="preview">&nbsp;</div>

The problem I have with the W3C standard is that constructing a node tree for even
mildly complex HTML is extremely tedious and fraught with peril.


Yes, that is fair to say, especially when the node is a document
fragment. But here, it is a simple text node and there are alternatives
(IE-specific and W3C DOM) for such specific case.

If you have a string containing unknown HTML that is moderately to highly complex, innerHTML seems the way
to go. Hand the string to the browser, let it render it. Parsing it (probably badly)
and attempting to construct a node tree out of it is simply duplicating the effort
already put into writing the browser and is better left to the user agent (via
innerHTML). After all, it _knows_ how to do that, it had to do it for the entire page
in the first place.

One negative drawback of this is that users do not learn, understand
what is the DOM, how to handle (create, insert, remove, replace, etc.)
DOM tree node. They hinder their long term understanding of DOM;
eventually (it's already the case IMO) they over-use or mis-use innerHTML.
On the other hand, if I am adding <form> elements or inserting additional fixed, known
content, I typically use the W3C methods.

I really wish innerHTML had been made part of the standard, considering it is probably
extremely easy to implement from the user agent developers' perspective.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq


Mozilla implemented innerHTML for the reasons (simplicity, ease of use)
you give.

DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Mozilla 1.7.3 :)
Jul 23 '05 #6
DU
news.versatel.de wrote:
function callBack() {
if (document.getElementById) {
var theDiv =
window.newWindowReference.document.getElementBy Id('preview');


DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Mozilla 1.7.3 :)

Thanks very much, but I get an "object expected" error in the line
"if(document.getElementById)..." in the newly opened window. Any idea what
may cause this?

Christian


We already covered and explained this. The new (popup) window maybe
created while the document which is supposed to be in it may not be
entirely loaded (with pointers referencing it in the memory heap) when
you're attempting to write into it. Asynchronous phenomenon. Grant gave
a good explanation and workaround for that:
[
There is no guarantee that the new window is open, or has a valid
document by the time the code referring to it execute. So, for starters,
printview.php should have <body onload="if (opener && opener.callBack)
opener.callBack();"> as a minimum.
]

DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Mozilla 1.7.3 :)
Jul 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Question | last post: by
1 post views Thread by PAD | last post: by
10 posts views Thread by Peter Altenberg | last post: by
4 posts views Thread by jsreblev | last post: by
8 posts views Thread by nescio | last post: by
2 posts views Thread by JS | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.