Re: WSDL Wizard
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 49384
interpreted = N
texte = I just want to clarify that you obviously don't want to include the brackets when you set the value of document.domain - replace {your domain here} with your actual domain (in quotes). :)-----Original Message----- From: Steve Contreras Sent: Wednesday, April 09, 2003 6:07 PM To: WebDNA-Talk@talk.smithmicro.com Subject: Re: WSDL Wizard 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/------------------------------------------------------------- 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/------------------------------------------------------------- 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:
I just want to clarify that you obviously don't want to include the brackets when you set the value of document.domain - replace {your domain here} with your actual domain (in quotes). :)-----Original Message----- From: Steve Contreras Sent: Wednesday, April 09, 2003 6:07 PM To: WebDNA-Talk@talk.smithmicro.com Subject: Re: WSDL Wizard 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/------------------------------------------------------------- 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/------------------------------------------------------------- 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/
Steve Contreras
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:
Variable Prices (1998)
Sku numbers (1997)
WebMerchant 1.6 and SHTML (1997)
Date question (2003)
syntax question, not in online refernce (1997)
Another question (1997)
emailer don't work (1998)
Fun with dates (1997)
WebMerchant and AVS (1998)
Simple Store (2000)
Emailer problem (2000)
Configuring E-mail (1997)
Upgrade to wsV (Email issue) (2004)
email [title] (1997)
New NT beta available (1997)
EIMS Problems (1997)
request for string functions (1998)
still having shipCost.db Problem (1997)
Need Advice for Setting up a Database (1999)
Checkboxes (1998)