How can I read html data of other site (with javascript or etc)?
in [JavaScript]
|
Prev: FAQ Topic - Internationalisation and Multinationalisation in javascript. (2010-03-23)
Next: FAQ Topic - How do I format a Date object with javascript? (2010-03-28)
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 15:13 Thomas 'PointedEars' Lahn wrote: > Sean Kinsey wrote: >> Thomas 'PointedEars' Lahn wrote: >>> Sean Kinsey wrote: >>> >> [Thomas 'PointedEars' Lahn wrote:] >>> >> > [Sean Kinsey wrote:] >>> [...] you need to make sure that an available feature under >>> probable circumstances works as you expect. Since that is next to >>> impossible, host object's properties, which by Specification exhibit >>> undefined behavior, are to be avoided for storing data. And certainly >>> doing otherwise is very far from being reliable. (I can see now that >>> you not only misuse existing properties of host objects, but you also >>> try to augment host objects with new properties, which is even worse >>> than the former.) >> >> I'm guessing your referring to the loadFn property? That was a quick >> fix and I have a plan for removing it. > > I am referring to your misusing the `window.name' and > `window.location.hash' properties. (And I see what you mean now.) I am further referring to your attempt of augmenting the host object referred to by `window' with new properties: easyXDM.js line 95 (indentation minimized, comments wrapped): | if (!config.local) { | // If no local was set, and we are unable to find a suitable file, | // then we resort to using the current window | config.local = window; | } | } | | if (config.local === window) { | // We are using the current window to listen to | config.usePolling = true; | config.useParent = true; Since the current window object is not subject to the SOP, you should be augmenting the global object (as referred to by `this' in the global execution context) or, to minimize potential name collisions, a user- defined native object instead. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Hans-Georg Michna on 28 Mar 2010 15:30 On Sat, 27 Mar 2010 16:41:41 -0700 (PDT), johnwlockwood wrote: >Mahdi, we were just talking about this in another thread. Sean Kinsey >has a library to help with this sort of thing easyXDM ( http://easyxdm.net/ >) Just looked at the web site and found it liberally sprinkled with a picture of a JavaScript routine for String.prototype.trim that embarrassingly uses two .replace calls where one would suffice. Hans-Georg
From: Sean Kinsey on 28 Mar 2010 15:31 To wrap this up, easyXDM is a library made to provide a means of transporting messages between two Javascript programs residing in documents separated by the Same-Origin policy. It does this reliably for all browsers supporting the postMessage interface, and all other browsers with similar traits as IE6/IE7. It is NOT targeted exclusively at IE, nor at Windows. If new standards etc are added to new browsers that solves this in a better way then support for these will be added to new versions of easyXDM. Those of my 'costumers' that wish to support these will upgrade, those who don't... well, they don't. Building the library around features defined in the base spec is not a viable option. First of all, that would mean opting not to use newer and faster features, and secondly, no such features exist. I appreciate all the feedback on issues as feature detection, augmenting host objects etc, but I do not appreciate the way you seem to want to undermine the considerable effort that has gone down to reach the level of interoperability that it has. If better solutions exist, let me know, then there is no use in me continuing my effort. Sean Kinsey
From: Sean Kinsey on 28 Mar 2010 15:35 On Mar 28, 9:30 pm, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > On Sat, 27 Mar 2010 16:41:41 -0700 (PDT), johnwlockwood wrote: > >Mahdi, we were just talking about this in another thread. Sean Kinsey > >has a library to help with this sort of thing easyXDM (http://easyxdm.net/ > >) > > Just looked at the web site and found it liberally sprinkled > with a picture of a JavaScript routine for String.prototype.trim > that embarrassingly uses two .replace calls where one would > suffice. > > Hans-Georg Nice one, attack the images I'm temporarily using on the website, and a few .replace calls... Real grown up...
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 15:38
Sean Kinsey wrote: > Thomas 'PointedEars' Lahn wrote: >> Sean Kinsey wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> Sean Kinsey wrote: >> >> >> [Thomas 'PointedEars' Lahn wrote:] >> >> >> An assumption not supported by the available facts, of course. >> >> > I have stated an assumption, you refer to facts. Where can I see >> >> > these facts? >> >> They come with experience for the most part. For example, you could, >> >> in the future, have a company as customer telling you that they would >> >> not update from IE 6/7 because the update would render their >> >> otherwise working software unusable. >> > What is the relevance for the above statement? >> (If you had quoted properly, you would have known.) You have stated the >> assumption that users would upgrade from IE 6/7. I have told you an >> example where they would not upgrade for a good reason. > > No, I stated the opposite. No, you did not, and I misread anyway: ,-<news:6d0994c7-fe78-482e-9ff2-7710b62dd04b(a)g19g2000yqe.googlegroups.com> | | OK, fine, I'm not an expert on the spec, but I do know that those | features _are_ indeed available in all the target browsers (that being | IE6/IE7). | And before you start on my potential lack of support for other | browsers not implementing the newer postMessage interface; this is a | choice made on the assumption that those using 'other' browsers than | IE6/7 are capable people who do update their software. But that is even worse because it assumes instead that A) There are no other browsers that support this feature but IE 6/7. B) People using "other" browsers are supposed to make updates. C) This feature is necessarily available in the version of the "other" browser that can be updated to. >> >> It is a particularly silly approach on the World Wide Web, though, to >> >> target only one specific browser brand instead of *at least* one DOM >> >> implementation with all its non-dead past and backwards-compatible >> >> future versions. >> > I don't target only one brand, so that line of arguments is void. >> You have said that you are targeting "IE". How is that not targeting >> only one brand? > > Yes, I said that, but I never stated that it was _limited_ to IE, only > that the fallback stacks primarily support IE6/7 as the amount of users > of IE6/7 constitutes the majority of the users who has a browser not > supporting the primary stack. True, you did not state that. Unfortunately, that other assumption is only equally unfounded. >> >> That said, you appear to be unaware that for IE 8 you are relying on >> >> a feature that originates from a *working* *draft* for a >> >> Specification, which is therefore in a constant state of flux and >> >> does not need to be supported (the same way) in the future. That is >> >> hardly raw material >> >> for production- quality code. >> > So, do you really think there is an inherent risk of IE8 suddenly >> > dropping, or changing its implementation of postMessage? >> > No, didn't think so.. >> Maybe not IE 8, but maybe 9, 10, ... > > And how is that relevant? Software built today should still work tomorrow with little or no extra effort. That is called responsible software development. > Do you propose I build the library around non-existing standards? Why should I propose something that you have done already, which I have explicitly recommended against? > The library uses feature testing (and I'll correct that code), It currently uses object inference, and one can only hope that the new version would not do that anymore. > it does not at any point use agent sniffing. Are you expecting some kind of applause now? UA-sniffing is a technique that was has been marked deprecated around 2000 CE. It is like your telling me that you have not written this article on a typewriter. >> > And yes, it uses encoding where necessary. >> >> Which only adds to the problem. >> >> > If it fails at transporting binary data then that is really not the >> > libraries fault as that is not its intention - but the user can easily >> > BASE64 encode/decode the message >> >> You miss the point. Start with: >> >> <http://support.microsoft.com/kb/208427/EN-US> > > The limit for use with hash fragments is actually 4050 or something, That remains to be seen. In any case, there is a limit imposed when there does not need to be one if you used the standards-compliant, reliable approach. > the limit you are referring to is the one used for the request to the > server. Not really. > Also, the library fragments and enqueues messages longer than the > limit, and yes, all encoding is done prior to fragmenting. Are you saying you would not only change `window.name' or `window.location.hash' once, but *several* times for sending the message? And I thought it could not get any worse. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |