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: johnwlockwood on 28 Mar 2010 12:44 On Mar 28, 5:50 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > johnwlockwood wrote: > > Mahdi Rad wrote: > >> can anybody help me? > > > Mahdi, we were just talking about this in another thread. > > What other thread are you talking about? I was referring to the thread titled 'jquery anonymous' > The OP's question is essentially about a *download* (retrieving > information), not about an upload (sending information). A working solution > (transparent HTTP proxying) has been proposed already. Isn't transparent HTTP proxying setup on a networking level of a user? Maybe I'm filling in the blanks of the question with the requirements of the problem I'm trying to solve, where any user can go to any site X.com and have site Y.com(the site I am developing) grab info from site X.com for some kind of processing. >>>we can read the value in the html site with javascript command like Because of this, I thought it appropriate to further the discussion of the javascript approach. the second part of the proposed solution: >> A less robust approach is to use dynamic script insertion to append >> script tag with src using x.com domain. seemed to describe a javascript way. Now, this has got me thinking that a solution for site Y to read the displayed contents of site X might be to use javascript to pass the current page's url to site Y and have the server app do an httpRequest on the url, parse the contents and then respond to the user with results, but that passes the parsing problem to server code and the server may see different content for one reason or another(cookies, authentication, or some other header). I also wanted to prompt more discussion of easyXDM among the browser scripting experts here, so I could make a more informed decision about relying on it. :) What about http://jibbering.com/faq/#frameRef on communicating between frames on different domains. Assuming the bookmarklet loaded a script that added an iframe containing site Y to the current page, is that more robust than what easyXDM does? or is that what easyXDM is doing? -John
From: David Mark on 28 Mar 2010 12:52 Sean Kinsey wrote: >> [Thomas 'PointedEars' Lahn wrote:] >>> [Sean Kinsey wrote:] >>> but I do know that those features _are_ indeed available in all the >>> target browsers (that being IE6/IE7). >> Whereas availability is well beside the point, though. > > Actually, when it comes to a pragmatic approach towards leveraging the > available features of a browser in order > to gain new features, then it is in fact the only point. Be very careful with that word "pragmatic" as it is typically bandied about by incompetents to justify their incompetent practices (see Dojo). Can't tell from the quoting (or lack thereof), but how does IE6/7 represent all the target browsers? And what features are we talking about? > >> 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? Also be careful of demanding to see _anything_ in cross-browser scripting, which is about understanding abstractions, _not_ about observations. That's the old "show me where it fails" fallacy. The ocean is much too large to go looking for dangers. Rest assured, they are out there. And the easy way to look at it is that you cannot observe browsers that do not yet exist (or ones you've never heard of). There are no guarantees in this business. Changes are sometimes required, but through understanding you can minimize their scope and thus minimize headaches and wasted time for your users. > >> To use that metaphor, you know only a *subset* of *current* nails. > Yes, and thats the 'nails' I target, and to be honest, the risk of IE6 > suddenly changing its behavior is minute, if not to say non-existent. > >>>> It does not apply to the `name' property of iframe objects. >>> Earlier tests showed that it did (and there are many references to it >>> on the internet), but I'll retest as many things has changed in the >>> library since that piece of code was written. >> That fact has not changed since MSHTML 5.0, and has been discussed in >> particular by Richard Cornford here. > > I just did a new test, and based on this I have removed the before > mentioned code. So now your users will have to download a new version. That could have been avoided had you not relied on "pragmatic" programming by observation. > >>>> The usual script-kiddie response. >>> No, that is the response of a pragmatist. Ouch. I'm telling you, that moniker is not desirable in this industry. >> Insulting those who mean to provide useful advice regarding the feasibility >> of an approach is not the response of a pragmatist; it is the response of >> an ignorant, if not a complete idiot. It should therefore not come as a >> surprise that reactions to such inappropriate behavior would not include >> any further pointers. > > I do apologize if it came across as an insult. > >>>> But it was in my next-to-latest posting instead. Learn to quote. >>> Will do >> You better really do it. >> >>>>> So in order to reach some goal (enabling cross domain messaging) I am >>>>> now _not_ allowed to use the only available techniques usable for said >>>>> goal? >>>> You are allowed to do anything stupid. Just do not expect it to work >>>> reliably, or promote it as such, and see yourself as having really >>>> understood what you are doing. >>> Well I do expect it to work reliably on all the target browser, >> There is your problem. > > A useless comment as my expectations are based on observable facts Programming by observation is the wrong approach. How many configurations does one version of IE have? For instance, for _years_, jQuery blew up immediately when ActiveX was disabled. Why? Resig had never _seen_ a grin without a cat. :) > >>> in fact, its an observable truth that it _does_ work in the target >>> browsers. >> How many combinations of data have you tested? > > All the relevant ones. > See previous comment. Which of the umpteen million configurations of IE do you consider relevant?
From: David Mark on 28 Mar 2010 12:54 johnwlockwood wrote: > On Mar 28, 5:50 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: >> johnwlockwood wrote: >>> Mahdi Rad wrote: >>>> can anybody help me? >>> Mahdi, we were just talking about this in another thread. >> What other thread are you talking about? > > I was referring to the thread titled 'jquery anonymous' > > >> The OP's question is essentially about a *download* (retrieving >> information), not about an upload (sending information). A working solution >> (transparent HTTP proxying) has been proposed already. > > Isn't transparent HTTP proxying setup on a networking level of a user? > Maybe I'm filling in the blanks of the question with the requirements > of the problem I'm trying to solve, where any user can go to any site > X.com and have site Y.com(the site I am developing) grab info from > site X.com for some kind of processing. > >>>> we can read the value in the html site with javascript command like > Because of this, I thought it appropriate to further the discussion of > the javascript approach. > > the second part of the proposed solution: >>> A less robust approach is to use dynamic script insertion to append >>> script tag with src using x.com domain. > seemed to describe a javascript way. > > Now, this has got me thinking that a solution for site Y to read the > displayed contents of site X might be to use javascript to pass the > current page's url to site Y and have the server app do an httpRequest > on the url, parse the contents and then respond to the user with > results, but that passes the parsing problem to server code and the > server may see different content for one reason or another(cookies, > authentication, or some other header). > > I also wanted to prompt more discussion of easyXDM among the browser > scripting experts here, so I could make a more informed decision about > relying on it. :) Definitely not at this time. > > What about http://jibbering.com/faq/#frameRef on communicating between > frames on different domains. Assuming the bookmarklet loaded a script > that added an iframe containing site Y to the current page, is that > more robust than what easyXDM does? or is that what easyXDM is doing? > It appears easyXDM does a lot of things. Unfortunately, at least some of them are ill-advised. I haven't had a chance to look at the script, but it appears Thomas has. :)
From: johnwlockwood on 28 Mar 2010 13:04 On Mar 28, 11:54 am, David Mark <dmark.cins...(a)gmail.com> wrote: > Definitely not at this time. Well, you know what I always say, "Ask and you shall have a better chance of receiving answers than if you did not ask.". I know it is not as smooth as "Ask and you shall receive.", but more accurate. :)
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 13:22
Sean Kinsey wrote: >> [Thomas 'PointedEars' Lahn wrote:] >> > [Sean Kinsey wrote:] >> > but I do know that those features _are_ indeed available in all the >> > target browsers (that being IE6/IE7). >> Whereas availability is well beside the point, though. > > Actually, when it comes to a pragmatic approach towards leveraging the > available features of a browser in order to gain new features, then it is > in fact the only point. No, further 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.) >> 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. Then there is the fact not requiring as much experience that there is no IE 7+ for Windows 2000, and Windows XP, Windows Vista, or Windows 7 would not run on those machines even if their owners could afford or be willing to do the hardware and OS upgrade. > > >> It does not apply to the `name' property of iframe objects. > > > Earlier tests showed that it did (and there are many references to it > > > on the internet), but I'll retest as many things has changed in the > > > library since that piece of code was written. > > > > That fact has not changed since MSHTML 5.0, and has been discussed in > > particular by Richard Cornford here. > > I just did a new test, and based on this I have removed the before > mentioned code. I hope you have also removed the `id' attribute, replaced the ludicrous absolute positioning and added some *real* feature tests while you were at it. >> To use that metaphor, you know only a *subset* of *current* nails. > > Yes, and thats the 'nails' I target, and to be honest, the risk of IE6 > suddenly changing its behavior is minute, if not to say non-existent. 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. 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 in order to reach some goal (enabling cross domain messaging) I >> >> > am now _not_ allowed to use the only available techniques usable >> >> > for said goal? >> >> You are allowed to do anything stupid. Just do not expect it to work >> >> reliably, or promote it as such, and see yourself as having really >> >> understood what you are doing. >> > Well I do expect it to work reliably on all the target browser, >> There is your problem. > > A useless comment as my expectations are based on observable facts Your observations are not worth much, given that there is not only the theoretical possibility but also practical evidence of failure of this approach. >> > in fact, its an observable truth that it _does_ work in the target >> > browsers. >> How many combinations of data have you tested? > > All the relevant ones. Given that you do not know what data the user of your library is going to transfer with it, that is quite an overconfident response, but not an unusual one under these circumstances. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 |