How can I read html data of other site (with javascript or etc)?

[Sean Kinsey]

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.

 

[Thomas 'PointedEars' Lahn]

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:

,-<[email protected]>
|
| 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?

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

 

[Thomas 'PointedEars' Lahn]

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.

Two?


PointedEars

 

[Thomas 'PointedEars' Lahn]

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

 

[David Mark]

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?

 

[Tim Down]

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

I haven't been able to find this trim method in a very quick look at
the site, but this is a pretty silly thing to criticize. Firstly, it
doesn't follow that a trim using a single call to a string's replace
method will be quicker than one with two calls (see
http://blog.stevenlevithan.com/archives/faster-trim-javascript).
Secondly, it's unlikely that the speed of a trim method will have any
noticeable impact on the overall speed of the script, unless it's
being used very heavily.

Tim

 

[Tim Down]

I haven't been able to find this trim method in a very quick look at
the site, but this is a pretty silly thing to criticize. Firstly, it
doesn't follow that a trim using a single call to a string's replace
method will be quicker than one with two calls (seehttp://blog.stevenlevithan.com/archives/faster-trim-javascript).
Secondly, it's unlikely that the speed of a trim method will have any
noticeable impact on the overall speed of the script, unless it's
being used very heavily.

Tim

OK, I understand now. The fact that it's in an image used all over the
site changes things and I at least understand why Hans-Georg made that
criticism.

Tim

 

[Bart Van der Donck]

for example there is site with addresswww.X.com, that has theprice
of some product:
<div id="product1">price: 100$</div>
now I wanna make sitewww.Y.comand then, I wanna read thepriceof
product1 which is in the sitewww.X.com
we can read the value in the html site with javascript command like
this:
String s = document.getElementById("product1").value
but how can we read this value in out of that site?

the improtant thing is : do it with code, beucause I wanna update my
site automatically

I don't want to toot my own horn, but I believe Ajax Cross Domain can
help you:
1. Load the body of X.com from Y.com
2. Extract the desired div from it
3. Use the value further at Y.com

www.ajax-cross-domain.com

 

[Bart Van der Donck]

Why the unnecessary complexity of a Perl server service? Why not
simply use a very light proxy server, as shown in
http://winhlp.com/node/699?

In so far I see, Ajax Cross Domain would use the same mechanism as
your JSP/PHP, but then done in Perl: grab URI, perform request, return
response. I think this is a dead simple principle; in my opinion not
complex at all; the elaboration might look complex if the environment/
technology is unknown, like e.g. I would find your solution more
difficult, because I am unfamiliar with JSP and PHP.

I agree that Ajax Cross Domain could be considered as a server (as any
CGI/PHP/ASP/...?), but I would rather look at it as a regular script,
a bit in the tradition of all those ancient content-grabbers, but then
then in a modern ajaxy coat.

To provide such a service for the public is nice, but would it
stand up to worldwide use? Probably not. People would have to
set up their own services, and then I fail to see the advantage
over a simple proxy server.

I'm quite positive that scripts like Ajax Cross Domain reflect a real
need, but you're absolutely right that multiple good solutions
available.

Cheers,