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 18:37 On Mar 29, 12:11 am, David Mark <dmark.cins...(a)gmail.com> wrote: > Claims is the operative word. ;) Once again, give me any specific use > case that you think calls for a design that begs for the use of your > script (or the like), and I'll give you a design that does not require > such a script. Good thing too as such scripts are clearly a bad idea. I can give you several :) Mashups, widgets that can communicate with it's hosts javascript program. Facebook Connnect-like api's where the providers application might need to interact with the user (authentication etc) Bookmarklets with the above mentioned requirements Integrating multiple web applications where client side events has to propagate between the programs I could give you more, but I think I made my point. All of the above examples are unable utilize server based messaging (as you are advocating for) without complex polling mechanisms. > > > > > Including scripts from different domains > > This is both security hazard > > You are generalizing. And you would seek to communicate with a script > from an untrusted source? How could you believe anything it says? I'm not generalizing. Including js from external domains are always a security hazard as their content will be executed. The messages transported by easyXDM are plain strings, they are not executed and incur no such danger. And by the way, the fact that you are even proposing including external scripts for such applications speaks its own when it comes to your view on javascript security (which I do know some things about). > > > AND it has nothing to do with > > communication between two javascript programs. > > Stop shouting and of course it has to do with communication between two > scripts (scripts from your domain and the one you inject from the other > from another). Did you not see that I said Javascript _programs_, not scripts? > > > It only allows a single javascript program to communicate with a > > server-side program on a different domain. > > Nonsense. ..... whops, my key got stuck again.. > > > > > Proxying > > This requires a server-side component, > > Yes, and that's something you can't can. I'd rather design for reality > than around your fantasies. And again, its not my fantasies, its my observable reality. (But I get the feeling that might not be the reality you perceive). > > but one javascript application, and one server-side application. > > Often that's all you need (as was the case with the original question). But its not a solution to the problems the library proposes a solution to, nor the before mentioned examples
From: Dr J R Stockton on 28 Mar 2010 12:49 In comp.lang.javascript message <cc40922b-b288-4d2a-aad7-69268cc5892b(a)z3 g2000yqz.googlegroups.com>, Sat, 27 Mar 2010 16:41:41, johnwlockwood <johnwlockwood(a)gmail.com> posted: > >also the FAQ for this group talks about cross domain scripting >http://jibbering.com/faq/#frameRef That section starts "To reference another frame on the same domain". That should be in <H4>, since otherwise it can be taken as applying to the whole of 10.2. Then <H4>To communicate between frames on different domains</H4>. The first subsection needs a mention of accessing the content as text, as in : DIR = Fram.contentDocument.body DIR = DIR.textContent || DIR.innerText // Is latter needed? Yes, IE8 -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7) Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
From: David Mark on 28 Mar 2010 19:03 Sean Kinsey wrote: > On Mar 29, 12:11 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> Claims is the operative word. ;) Once again, give me any specific use >> case that you think calls for a design that begs for the use of your >> script (or the like), and I'll give you a design that does not require >> such a script. Good thing too as such scripts are clearly a bad idea. > > I can give you several :) > Mashups, widgets that can communicate with it's hosts javascript > program. That's not specific enough. > Facebook Connnect-like api's where the providers application might > need to interact with the user (authentication etc) That sounds like a truly awful idea, so perhaps a truly awful design is appropriate. :) > Bookmarklets with the above mentioned requirements Too general. > Integrating multiple web applications where client side events has to > propagate between the programs Another very ill-advised design. > > I could give you more, but I think I made my point. Nope. > All of the above examples are unable utilize server based messaging > (as you are advocating for) without complex polling mechanisms. If you have gotten that far in the design of your app and your only two options are the hacks you advocate and complex polling, you need to put it in reverse. ;) > > >> >> >>> Including scripts from different domains >>> This is both security hazard >> You are generalizing. And you would seek to communicate with a script >> from an untrusted source? How could you believe anything it says? > I'm not generalizing. Including js from external domains are always a > security hazard as their content will be executed. Except when the external domain is trusted. > The messages transported by easyXDM are plain strings, they are not > executed and incur no such danger. No kidding. But that is beside the point. > And by the way, the fact that you are even proposing including > external scripts for such applications speaks its own when it comes to > your view on javascript security (which I do know some things about). No, it speaks to your tendency to misconstrue what I am saying. > >>> AND it has nothing to do with >>> communication between two javascript programs. >> Stop shouting and of course it has to do with communication between two >> scripts (scripts from your domain and the one you inject from the other >> from another). > > Did you not see that I said Javascript _programs_, not scripts? LOL. Enough said. > >>> It only allows a single javascript program to communicate with a >>> server-side program on a different domain. >> Nonsense. > > .... whops, my key got stuck again.. > >> >> >>> Proxying >>> This requires a server-side component, >> Yes, and that's something you can't can. I'd rather design for reality >> than around your fantasies. > > And again, its not my fantasies, its my observable reality. (But I get > the feeling that might not be the reality you perceive). You just don't get it. Your observations are insignificant. You can't observe what future browsers will do, nor can you observe the myriad browsers/configurations that you haven't heard of. And as there are always better design alternatives, there is no good reason to rely on something "proven" by your insignificant observations. > >>> but one javascript application, and one server-side application. >> Often that's all you need (as was the case with the original question). > > But its not a solution to the problems the library proposes a solution > to, nor the before mentioned examples > There are virtually no problems in existence that require a "solution" like yours. But, as mentioned, for those who have boxed themselves in by listening to people who think their observations are significant enough to shape cross-browser designs...
From: Sean Kinsey on 28 Mar 2010 19:37 Consider this my last post on this thread, you are clearly unable to grasp the real topic of this discussion, nor bring anything constructive to it. On Mar 29, 1:03 am, David Mark <dmark.cins...(a)gmail.com> wrote: > Sean Kinsey wrote: > > On Mar 29, 12:11 am, David Mark <dmark.cins...(a)gmail.com> wrote: > >> Claims is the operative word. ;) Once again, give me any specific use > >> case that you think calls for a design that begs for the use of your > >> script (or the like), and I'll give you a design that does not require > >> such a script. Good thing too as such scripts are clearly a bad idea. > > > I can give you several :) > > Mashups, widgets that can communicate with it's hosts javascript > > program. > > That's not specific enough. So read into it, use that big brain of yours. > > > Facebook Connnect-like api's where the providers application might > > need to interact with the user (authentication etc) > > That sounds like a truly awful idea, so perhaps a truly awful design is > appropriate. :) Yeah, creating a service that millions use daily (the connect part, not the core service) is obviously an awful design. > > > Bookmarklets with the above mentioned requirements > > Too general. Look up the term on wikipedia, or actually, dont't bother, if its not defined in ECMA-262 then it cannot be trusted. > > > Integrating multiple web applications where client side events has to > > propagate between the programs > > Another very ill-advised design. Strangely thats not how our customers sees it. How about that.. > > > > > I could give you more, but I think I made my point. > > Nope. Yes I did, not my fault that you are unable to 'get it'. > > > All of the above examples are unable utilize server based messaging > > (as you are advocating for) without complex polling mechanisms. > > If you have gotten that far in the design of your app and your only two > options are the hacks you advocate and complex polling, you need to put > it in reverse. ;) Well, at least I have contributed with a library that people actually use, that people find beneficial, that people find to be time and cost saving, that, again - does work. But these are concepts that I believe you are unable to grasp, why would you otherwise name your library 'My Library', but not also that, claim that it is '... the most innovative and influential browser scripting (Javascript) library to ever hit the Web' <http://www.linkedin.com/in/davidmark> Talk about delusion of grandeur. > > But its not a solution to the problems the library proposes a solution > > to, nor the before mentioned examples > > There are virtually no problems in existence that require a "solution" > like yours. Well, for those of us living in the Real World, there is. > But, as mentioned, for those who have boxed themselves in > by listening to people who think their observations are significant > enough to shape cross-browser designs... By the way, its funny how you would rather rely on prehistoric features that with use would litter the DOM with script tags, increase memory usage, incur unnecessary amounts of GC, than to even think about using newer additions to the standard etc. As you advocate strongly for supporting _all_ browsers on _all_ platforms I can only assume that you are a strong opponent to the 5. edition of ECMA-626 and everything 'HTML5'. But 'nuff said. I'm sick of your nonconstructive criticism, and for the sake of those reading this newsgroup; Please Stop Trolling.
From: David Mark on 28 Mar 2010 20:25
Sean Kinsey wrote: > Consider this my last post on this thread, you are clearly unable to > grasp the real topic of this discussion, nor bring anything > constructive to it. Promises, promises. :) > > On Mar 29, 1:03 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> Sean Kinsey wrote: >>> On Mar 29, 12:11 am, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> Claims is the operative word. ;) Once again, give me any specific use >>>> case that you think calls for a design that begs for the use of your >>>> script (or the like), and I'll give you a design that does not require >>>> such a script. Good thing too as such scripts are clearly a bad idea. >>> I can give you several :) >>> Mashups, widgets that can communicate with it's hosts javascript >>> program. >> That's not specific enough. > > So read into it, use that big brain of yours. The nead (sic) is for you to cite a specific example that you think requires a bunch of cobbled together hacks. > >>> Facebook Connnect-like api's where the providers application might >>> need to interact with the user (authentication etc) >> That sounds like a truly awful idea, so perhaps a truly awful design is >> appropriate. :) > > Yeah, creating a service that millions use daily (the connect part, > not the core service) is obviously an awful design. LOL. Millions of users does not imply a good (or even a competent) design. You seem to have a problem with basic logic. It's odd that I see so much of that in the field of programming (particularly browser scripting), but it does account for the prevalence of futile designs. > >>> Bookmarklets with the above mentioned requirements >> Too general. > > Look up the term on wikipedia, or actually, dont't bother, if its not > defined in ECMA-262 then it cannot be trusted. I'm obviously familiar with bookmarklets. What I want is a specific example of a design that requires a bookmarklet plus your wonder script (as in wonder if it will work). > >>> Integrating multiple web applications where client side events has to >>> propagate between the programs >> Another very ill-advised design. > > Strangely thats not how our customers sees it. How about that.. I'm sure your customers see whatever it is you pitch down their throats. Doesn't make it right. > >> >> >>> I could give you more, but I think I made my point. >> Nope. > > Yes I did, not my fault that you are unable to 'get it'. You are wasting my time. :( > >>> All of the above examples are unable utilize server based messaging >>> (as you are advocating for) without complex polling mechanisms. >> If you have gotten that far in the design of your app and your only two >> options are the hacks you advocate and complex polling, you need to put >> it in reverse. ;) > > Well, at least I have contributed with a library that people actually > use, that people find beneficial, > that people find to be time and cost saving, that, again - does work. Marketing drivel. > But these are concepts that I believe you are unable to grasp, why > would you otherwise name your library 'My Library', Why would MS name one of their shell views "My Computer" and why didn't you read to the bottom of the page? :) > but not also that, > claim that it is '... the most innovative and influential browser > scripting (Javascript) library to ever hit the Web' > <http://www.linkedin.com/in/davidmark> > Talk about delusion of grandeur. No history is what it is. Perhaps this will clear things up a bit for you:- http://www.cinsoft.net/host.html ....in other words, my library has likely influenced your library, just as it has jQuery, Dojo, etc. Whether you know that or not is irrelevant. ;) > >>> But its not a solution to the problems the library proposes a solution >>> to, nor the before mentioned examples >> There are virtually no problems in existence that require a "solution" >> like yours. > > Well, for those of us living in the Real World, there is. Where do these people come from? Every author or every lousy script out there thinks that the Real World desperately needs their drivel. Talk about... > >> But, as mentioned, for those who have boxed themselves in >> by listening to people who think their observations are significant >> enough to shape cross-browser designs... > > By the way, its funny how you would rather rely on prehistoric > features that with use would litter the DOM with script tags, increase > memory usage, incur unnecessary amounts of GC, than to even think > about using newer additions to the standard etc. You are just generalizing (and babbling) again. You have no idea what I would rather do. I asked you to provide a specific context that requires a solution, but you haven't been able to come up with one. So I guess you'll never know. > As you advocate > strongly for supporting _all_ browsers on _all_ platforms I can only > assume that you are a strong opponent to the 5. edition of ECMA-626 > and everything 'HTML5'. How does that follow? Have you ever heard of progressive enhancement? :) > > But 'nuff said. I'm sick of your nonconstructive criticism, and for > the sake of those reading this newsgroup; Please Stop Trolling. There it is! All cut from the same cloth (polyester I imagine). :) And you asked for the criticism, jackass. Giving it to you is "trolling" in your "real world". Mention "snark" for the hat trick. :) |