Re: WSDL Wizard
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 49387
interpreted = N
texte = It's my pleasure. :)I hope it works out for you.-----Original Message-----From: Gary Krockover [mailto:gary@garykrockover.com]Sent: Wednesday, April 09, 2003 6:45 PMTo: WebDNA-Talk@talk.smithmicro.comSubject: Re: WSDL WizardThanks Steve, this is a mouthful to say the least. I think I'll print itout and study it in my library tonight....I'll let you all know how it goes (er, the HTML editor that is, not my studysession) : )GK> Basically the crux of the matter concerns browsers' inherent cross-domain> security for DOM; i.e. browsers should not allow apage/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 codethat> was apparently broken after updating/testing 6.0.28 (that previouslyworked> 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 yourefresh> the source for the frame/iframe; i.e. all of your pages havedocument.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 theurge> to find windows or iframes via some recursive findWindow function call> you've built... especially if each of your iframes act independently ofone> another. If an iframe is being reloaded or re-renders contentdynamically,> there are timing issues during which the document.domain appears to be> undefined while the iframe's source is reloaded or set. So, even thoughyou> 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/orread> 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 solutionis> 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 lookingForThisIframeis> 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 betis> to create some sort of global monitor object (probably some statichidden> window or frame/iframe) that you know will be defined for the life of the> application. Accomplish synchronization by signaling this globalmonitor> 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 awindow/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 arefamiliar> 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 DOMmanipulation/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 athttp://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. Itwill> > 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 WSDLinformation> > fundamentally requires extensive XML parsing and validation, TCPconnect,> > etc., ... all stuff that WebDNA does well. Since we built thatcapability> > 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 issuesthan> 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 toWeb 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:
It's my pleasure. :)I hope it works out for you.-----Original Message-----From: Gary Krockover [mailto:gary@garykrockover.com]Sent: Wednesday, April 09, 2003 6:45 PMTo: WebDNA-Talk@talk.smithmicro.comSubject: Re: WSDL WizardThanks Steve, this is a mouthful to say the least. I think I'll print itout and study it in my library tonight....I'll let you all know how it goes (er, the HTML editor that is, not my studysession) : )GK> Basically the crux of the matter concerns browsers' inherent cross-domain> security for DOM; i.e. browsers should not allow apage/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 codethat> was apparently broken after updating/testing 6.0.28 (that previouslyworked> 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 yourefresh> the source for the frame/iframe; i.e. all of your pages havedocument.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 theurge> to find windows or iframes via some recursive findWindow function call> you've built... especially if each of your iframes act independently ofone> another. If an iframe is being reloaded or re-renders contentdynamically,> there are timing issues during which the document.domain appears to be> undefined while the iframe's source is reloaded or set. So, even thoughyou> 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/orread> 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 solutionis> 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 lookingForThisIframeis> 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 betis> to create some sort of global monitor object (probably some statichidden> window or frame/iframe) that you know will be defined for the life of the> application. Accomplish synchronization by signaling this globalmonitor> 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 awindow/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 arefamiliar> 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 DOMmanipulation/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 athttp://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. Itwill> > 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 WSDLinformation> > fundamentally requires extensive XML parsing and validation, TCPconnect,> > etc., ... all stuff that WebDNA does well. Since we built thatcapability> > 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 issuesthan> 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 toWeb 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:
method of payment (1997)
[WebDNA] favorite db server with webDNA (2011)
WebCommerce: Folder organization ? (1997)
[WebDNA] WebDNA restart script (2015)
WebDNA on OS X Tiger (2006)
RE: Credit card processing - UK (1997)
Date Range Sorting (1997)
Anyone using WebCat UNIX on a busy server yet? (1999)
Width & Height (1998)
Cancel Subscription (1996)
WebCat with WebTen (1998)
[WebDNA] 6.2.1 fails on Apache 2.4.6 (2014)
Append command(2) (2000)
Help! WebCat2 bug (Ben's input) (1997)
[/application] error? (1997)
Multithreading of [replace] (1999)
Help! WebCat2 bug (1997)
WC1.6 to WC2 date formatting (1997)
How to Display text in empty fields (1997)
Details of shipping - Totalqty calculations (1997)