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 16:05 Sean Kinsey wrote: > Thomas 'PointedEars' Lahn 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. No, that is what you have essentially said. > I only feature test. The library is agnostic to vendors, brands and > versions. At the moment (2.0.1.77, which is the newest I could download), it evidently is not. (And I am not talking about the window.attachEvent inference, but about the other things I have pointed out.) > And by the way, the fallback method, FIM, is actually within the > standard. The fallback methods are `window.name' and `window.location.hash' (or, AIUI you explain below, `window.location' with a changing fragment part). So which part of "misuse", "proprietary", and "error-prone" did you not understand? >> > 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, Which is limited in length in IE ... > I do not access the .hash property because I know this not to be > standard. `window.name' is not standard either. > 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'. Oh, I am sorry. It was supposed to sound like "It should not be done like this at all, not even once." instead. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 16:08 Sean Kinsey wrote: > Thomas 'PointedEars' Lahn 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. <news:hom32g$g5m$1(a)news.eternal-september.org> > 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. Two? PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 16:22 Sean Kinsey wrote: > Thomas 'PointedEars' Lahn wrote: >> Thomas 'PointedEars' Lahn wrote: >> (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? Sorry, my bad. In the quoted code you are not doing this. Only the next statement is a bit curious and I am not sure if it is supposed to work reliably given the prior assignment (but it is not augmentation either): | parameters.xdm_e = encodeURIComponent(config.local = location.protocol + | "//" + location.host + location.pathname + location.search); > easyXDM does not augment ANY host objects, I will have to take your word for it, since I cannot be bothered to dig through the source code anymore. > and the only global object introduced is 'easyXDM'. "global object" refers to something different, though. 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:42 Sorry for not attributing the specific messages, I have yet to learn how to do that. [David mark wrote:] > 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). [Thomas 'PointedEars' Lahn wrote:] > For crying out loud, a much better approach has been proposed here already. The above was the reason for me expecting at least two solutions (other than the ones I'm using). I can for some reason not find any such solutions mentioned in the thread, (that is, solutions that solve the problems that easyXDM advertises to solve, and not the one stated by the first message in the thread), so it would be really nice if you could sum them up.
From: David Mark on 28 Mar 2010 17:31
Sean Kinsey wrote: > 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. The issue is already resting (in pieces of course). Perhaps re-read the thread? > > 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. You have blinders on. There are other ways of accomplishing cross-domain communication that have nothing to do with a canned script. For one, you can just inject a SCRIPT element from another domain. No IFRAME (or canned script) necessary. In the interest of time, the second one is just as obvious and involves a server side script (search the thread for the word "proxy"). Realize that those two methods alone pretty much make your project a moot point. They don't do exactly the same thing that you have attempted to can, but nobody should need or want such a can of worms. ;) Think of it from the perspective of somebody designing a project today (after reading this thread). Do you think it would be pragmatic of them to design it around obvious ill-advised, time-stamped folly or around things that have worked (and will continue to work) virtually forever. Now, for the uninformed who have already boxed themselves in because they knew of your project (or Dojo or other follies) and assumed that it worked, your thing might be their only shot. That's a shame for them and who is to blame? |