Re: WSDL Wizard
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 49386
interpreted = N
texte = Thanks Steve, this is a mouthful to say the least. I think I'll print it out and study it in my library tonight....I'll let you all know how it goes (er, the HTML editor that is, not my study session) : )GK > Basically the crux of the matter concerns browsers' inherent cross-domain > security for DOM; i.e. browsers should not allow a page/window/frame/iframe > from one domain to manipulate the DOM of a page/window/frame/iframe on a > different domain. It makes sense and is especially touchy in IFRAME > elements for some reason. It *appears* that I.E. 6.0.28 now enforces this > rule even more strictly than it did before. While working to fix code that > was apparently broken after updating/testing 6.0.28 (that previously worked > on 6.0.26), I was pleasantly surprised to find that many of other > browser/DOM-manipulation issues were resolved. Here is what I did: > > - First, I ensured that each page explicity sets its domain via the DOM > javascript function call: document.domain = {your domain here};. This > property is quite naturally assumed to be set by default but apparently it > is not (at least it appears ineffective even after verifying its default > value is the same for two different pages that do, in fact, reside on the > same domain). > - IFRAME and FRAME elements: If you are rendering content dynamically, > simply re-set the document.domain to the same as the above when you refresh > the source for the frame/iframe; i.e. all of your pages have document.domain > set explicity. > - If your application window/frame structure is organized hierarchically > (which is typical if you need to use frames/iframes), try to avoid the urge > to find windows or iframes via some recursive findWindow function call > you've built... especially if each of your iframes act independently of one > another. If an iframe is being reloaded or re-renders content dynamically, > there are timing issues during which the document.domain appears to be > undefined while the iframe's source is reloaded or set. So, even though you > may correctly set the document.domain to be identical to other > windows/frames/iframes via some javascript in the source for that iframe, > during the time it is being loaded, if you attempt to manipulate and/or read > the pending iframe's DOM, you will more than likely receive a permission > denied or access denied error. In this case, the best solution is to: > a.) try to avoid recursive function calls that attempt to find > window objects or iframe objects via some condition matching that involves > reading the DOM of the window being sought (e.g. code: if > (currentIframe.name == lookingForThisFrame){...}) ... a better solution is > to name the window/frame/iframe with the HTML name attribute and access > the object via static dotted notation; e.g. > window.parent.opener.lookingForThisIframe where lookingForThisIframe is > the name of the iframe being sought. > b.) re-set the document.domain property each time you refresh the > source of the iframe/frame. > c.) be aware of timing issues involved with dynamically > rendering/refreshing iframe content... if you must do this, the best bet is > to create some sort of global monitor object (probably some static hidden > window or frame/iframe) that you know will be defined for the life of the > application. Accomplish synchronization by signaling this global monitor > when the iframe is being refreshed. Always check with this monitor object > if a window/frame is pending when you need to manipulate DOM across > windows/frames/iframes. If the monitor indicates that a window/frame/iframe > is pending, simply wait until the object is finished loading and then > require that it signal the monitor when it is done. These techniques are > common in multi-threaded synchronization programming so if you are familiar > with that stuff, it should help. > > At any rate, following these guidelines has cleared up most, if not all, > browser-based issues related to cross-frame/window DOM manipulation/reading. > Have a go at it and let me know how it turns out for you. > > -----Original Message----- > From: Gary Krockover [mailto:gary@garykrockover.com] > Sent: Wednesday, April 09, 2003 5:28 PM > To: WebDNA-Talk@talk.smithmicro.com > Subject: Re: WSDL Wizard > > > Any chance of learning what you all are doing to overcome the iFrame/DOM > issue for the wizard? I've had that issue on my WebDNA HTML editor (that > uses an iFrame) for the Mac and have not been successful in finding a > workaround. > > The editor, should you want to look at it, is at http://www.webcatdev.net/. > > Thanks, > GK > > ----- Original Message ----- > From: Phillip Bonesteele
> To: WebDNA Talk > Sent: Wednesday, April 09, 2003 6:30 PM > Subject: Re: WSDL Wizard > > > > > > Stuart, > > > > The iFrame/DOM issues with the UI affecting different browsers are close > to > > being resolved ... so the Mac versus PC point will soon be moot. It will > > shortly work with various flavors of IE, Netscape, etc., on Mac or PC. > The > > updated templates will then be available for download for Developer and > > Enterprise Editions. > > > > The main reason why it's a browser based application is because the bulk > of > > the work of identifying web services and building all the WSDL information > > fundamentally requires extensive XML parsing and validation, TCPconnect, > > etc., ... all stuff that WebDNA does well. Since we built that capability > > into the 5.0 engine along with all the WSDL processing, it made a lot of > > sense to leverage that as a server side application, particularly given > the > > generated code will ultimately be server side anyway. The final step of > the > > wizard actually executes the sample code in a temporary WebDNA template, > > making a live call to the selected web service and showing you the > resulting > > response. > > > > So I'm not sure what you mean by going against everything we've done > before > > ... I don't think anyone would want this as a 'thick' client application > or > > even client/server, which have even bigger platform dependency issues than > a > > browser based UI communicating to a web-server application. > Fundamentally, > > we've all been building web-based applications with WebDNA all along. > > Please clarify the point if I'm missing something ... > > > > Phil B. > > > > > > -----Original Message----- > > From: Stuart Tremain [mailto:development@idfk.com.au] > > Sent: Wednesday, April 09, 2003 3:57 PM > > To: WebDNA-Talk@talk.smithmicro.com > > Subject: Re: WSDL Wizard > > > > And a PC with IE 6.0.026 > > > > > > Terrific value for a Macintosh based development studio (NOT). > > > > > > Phil, why does it have to be so browser based, seems to go against > > everything that you have done before ? > > > > > > > > On Thursday, April 10, 2003, at 05:10 AM, Alain Russell wrote: > > > > >> IE 6.0.026 > > Regards > > > > Stuart Tremain > > idfk web developments > > 114a/40 yeo street neutral bay 2089 australia > > t +612 9908 2134 > > f +612 9908 4837 ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
Thanks Steve, this is a mouthful to say the least. I think I'll print it out and study it in my library tonight....I'll let you all know how it goes (er, the HTML editor that is, not my study session) : )GK > Basically the crux of the matter concerns browsers' inherent cross-domain > security for DOM; i.e. browsers should not allow a page/window/frame/iframe > from one domain to manipulate the DOM of a page/window/frame/iframe on a > different domain. It makes sense and is especially touchy in IFRAME > elements for some reason. It *appears* that I.E. 6.0.28 now enforces this > rule even more strictly than it did before. While working to fix code that > was apparently broken after updating/testing 6.0.28 (that previously worked > on 6.0.26), I was pleasantly surprised to find that many of other > browser/DOM-manipulation issues were resolved. Here is what I did: > > - First, I ensured that each page explicity sets its domain via the DOM > javascript function call: document.domain = {your domain here};. This > property is quite naturally assumed to be set by default but apparently it > is not (at least it appears ineffective even after verifying its default > value is the same for two different pages that do, in fact, reside on the > same domain). > - IFRAME and FRAME elements: If you are rendering content dynamically, > simply re-set the document.domain to the same as the above when you refresh > the source for the frame/iframe; i.e. all of your pages have document.domain > set explicity. > - If your application window/frame structure is organized hierarchically > (which is typical if you need to use frames/iframes), try to avoid the urge > to find windows or iframes via some recursive findWindow function call > you've built... especially if each of your iframes act independently of one > another. If an iframe is being reloaded or re-renders content dynamically, > there are timing issues during which the document.domain appears to be > undefined while the iframe's source is reloaded or set. So, even though you > may correctly set the document.domain to be identical to other > windows/frames/iframes via some javascript in the source for that iframe, > during the time it is being loaded, if you attempt to manipulate and/or read > the pending iframe's DOM, you will more than likely receive a permission > denied or access denied error. In this case, the best solution is to: > a.) try to avoid recursive function calls that attempt to find > window objects or iframe objects via some condition matching that involves > reading the DOM of the window being sought (e.g. code: if > (currentIframe.name == lookingForThisFrame){...}) ... a better solution is > to name the window/frame/iframe with the HTML name attribute and access > the object via static dotted notation; e.g. > window.parent.opener.lookingForThisIframe where lookingForThisIframe is > the name of the iframe being sought. > b.) re-set the document.domain property each time you refresh the > source of the iframe/frame. > c.) be aware of timing issues involved with dynamically > rendering/refreshing iframe content... if you must do this, the best bet is > to create some sort of global monitor object (probably some static hidden > window or frame/iframe) that you know will be defined for the life of the > application. Accomplish synchronization by signaling this global monitor > when the iframe is being refreshed. Always check with this monitor object > if a window/frame is pending when you need to manipulate DOM across > windows/frames/iframes. If the monitor indicates that a window/frame/iframe > is pending, simply wait until the object is finished loading and then > require that it signal the monitor when it is done. These techniques are > common in multi-threaded synchronization programming so if you are familiar > with that stuff, it should help. > > At any rate, following these guidelines has cleared up most, if not all, > browser-based issues related to cross-frame/window DOM manipulation/reading. > Have a go at it and let me know how it turns out for you. > > -----Original Message----- > From: Gary Krockover [mailto:gary@garykrockover.com] > Sent: Wednesday, April 09, 2003 5:28 PM > To: WebDNA-Talk@talk.smithmicro.com > Subject: Re: WSDL Wizard > > > Any chance of learning what you all are doing to overcome the iFrame/DOM > issue for the wizard? I've had that issue on my WebDNA HTML editor (that > uses an iFrame) for the Mac and have not been successful in finding a > workaround. > > The editor, should you want to look at it, is at http://www.webcatdev.net/. > > Thanks, > GK > > ----- Original Message ----- > From: Phillip Bonesteele > To: WebDNA Talk > Sent: Wednesday, April 09, 2003 6:30 PM > Subject: Re: WSDL Wizard > > > > > > Stuart, > > > > The iFrame/DOM issues with the UI affecting different browsers are close > to > > being resolved ... so the Mac versus PC point will soon be moot. It will > > shortly work with various flavors of IE, Netscape, etc., on Mac or PC. > The > > updated templates will then be available for download for Developer and > > Enterprise Editions. > > > > The main reason why it's a browser based application is because the bulk > of > > the work of identifying web services and building all the WSDL information > > fundamentally requires extensive XML parsing and validation, TCPconnect, > > etc., ... all stuff that WebDNA does well. Since we built that capability > > into the 5.0 engine along with all the WSDL processing, it made a lot of > > sense to leverage that as a server side application, particularly given > the > > generated code will ultimately be server side anyway. The final step of > the > > wizard actually executes the sample code in a temporary WebDNA template, > > making a live call to the selected web service and showing you the > resulting > > response. > > > > So I'm not sure what you mean by going against everything we've done > before > > ... I don't think anyone would want this as a 'thick' client application > or > > even client/server, which have even bigger platform dependency issues than > a > > browser based UI communicating to a web-server application. > Fundamentally, > > we've all been building web-based applications with WebDNA all along. > > Please clarify the point if I'm missing something ... > > > > Phil B. > > > > > > -----Original Message----- > > From: Stuart Tremain [mailto:development@idfk.com.au] > > Sent: Wednesday, April 09, 2003 3:57 PM > > To: WebDNA-Talk@talk.smithmicro.com > > Subject: Re: WSDL Wizard > > > > And a PC with IE 6.0.026 > > > > > > Terrific value for a Macintosh based development studio (NOT). > > > > > > Phil, why does it have to be so browser based, seems to go against > > everything that you have done before ? > > > > > > > > On Thursday, April 10, 2003, at 05:10 AM, Alain Russell wrote: > > > > >> IE 6.0.026 > > Regards > > > > Stuart Tremain > > idfk web developments > > 114a/40 yeo street neutral bay 2089 australia > > t +612 9908 2134 > > f +612 9908 4837 ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Gary Krockover
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Installation webCatalog (French speakers please help) (1998)
Re1000001: Setting up shop (1997)
Setting up WebCatalog with Retail Pro data (1996)
New public beta available (1997)
[OT] Might be of interest... (2006)
TinyStore example templates (1998)
[WebDNA] prevent database duplicates (2019)
[WebDNA] location line item change password (2011)
Follow-Up to: Removing [showif] makes a big difference in speed (1997)
Stopping bad HTML propagation ? (1997)
RE: Automatic Forwarding using WebCat (1997)
filemaker - orderfile (1997)
Great product and great job ! (1997)
RE: Can a database get stomped by simultaneous access? (1997)
Add a field to the error log? (1997)
More on the email templates (1997)
URGENT! ACGI Stopped!!!! (1997)
Re[2]: New syntax feedback for 4.0 (2000)
WCS Newbie question (1997)
Protect (1997)