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: Sean Kinsey on 28 Mar 2010 15:39 On Mar 28, 9:13 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > 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. And exactly where am I augmenting, no, attempting to augment the window host object? easyXDM does not augment ANY host objects, and the only global object introduced is 'easyXDM'.
From: David Mark on 28 Mar 2010 15:47 Sean Kinsey wrote: > 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. Which you should never need to do if you just consider more practical designs (that, unfortunately for your endeavor, you cannot can. > It does this reliably for all browsers supporting the postMessage > interface, and all other browsers with similar traits as IE6/IE7. So it is not an appropriate solution for a public-facing Website. > > 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. Neither is building it around non-standard recommendations and hacks. > First of all, that would mean opting not to use newer and faster > features, > and secondly, no such features exist. Huh? > > 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. How is your wasted time (that you seek to pass on to others) the fault of this newsgroup? > If better solutions exist, let me know, then there is no use in me > continuing my effort. > At least two solutions have already been proposed for _specific_ contexts. Seeking to can a general-purpose solution is usually bad news and that has been the case with this project. I am truly sorry about your luck, but don't blame the messenger(s).
From: Sean Kinsey on 28 Mar 2010 15:51 On Mar 28, 9:38 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > 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. All wrong. I only feature test. The library is agnostic to vendors, brands and versions. And by the way, the fallback method, FIM, is actually within the standard. > > 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? window.name, no, and not window.location.hash either actually I set the full URL, I do not access the .hash property because I know this not to be standard. And seriously, it actually sounds like your saying that 'if you cannot pass the message by changing the hash only once, then it should't be done at all'. Seriously..
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 15:52 Sean Kinsey wrote: > To wrap this up, You have a peculiar way of saying "to bury all valid counter-arguments made before below a load of advertisement nonsense". > 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. We know what it *advertises* to do, thank you very much. > It does this reliably for all browsers supporting the postMessage > interface, and all other browsers with similar traits as IE6/IE7. By definition it cannot. > It is NOT targeted exclusively at IE, nor at Windows. Good. > 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. Existing standards solve this problem completely already. > Those of my 'costumers' that wish to support these will upgrade, those > who don't... well, they don't. You do not seem to understand that your customers are not concerned when it comes to compatibility of a script library, but the customers of your customers, i.e. the visitors of their Web sites. IOW, the worm must be tasty for the fish, not the fisherman. > Building the library around features defined in the base spec is not a > viable option. Yes, it is. It has been done before. > First of all, that would mean opting not to use newer and faster > features, No, it would not. > and secondly, no such features exist. You are mistaken. > 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. I hate to break it to you, stupid, but for the most part you have wasted your time with this. Like David said, it happens to the best of us. > If better solutions exist, let me know, then there is no use in me > continuing my effort. For crying out loud, a much better approach has been proposed here already. 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: Sean Kinsey on 28 Mar 2010 16:02
On Mar 28, 9:52 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Sean Kinsey wrote: > > If better solutions exist, let me know, then there is no use in me > > continuing my effort. > > For crying out loud, a much better approach has been proposed here already. Please recap those and we can put this issue to rest. I am really exited now that I hear that there are actually _two_ methods other than FIM and window.name manipulation and window.postMessage that allow you to pass string messages, JSON (via serialization) and expose RPC bypassing the SOP. |