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

[Mahdi Rad]

for example there is site with address www.X.com, that has the price
of some product:
<div id="product1">price: 100$</div>
now I wanna make site www.Y.com and then, I wanna read the price of
product1 which is in the site www.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

can anybody help me?

 

[Garrett Smith]

for example there is site with address www.X.com, that has the price
of some product:
<div id="product1">price: 100$</div>
now I wanna make site www.Y.com and then, I wanna read the price of
product1 which is in the site www.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?

Use a proxy. Your server can make a request to x.com to request the
price. Define this in a "getAPrice" server side program.

Your *page* makes a request to your "getAPrice" program, which then
requests to other domain.

If you are using JSP, c:import tag is a very simple way to write a proxy
server.

A less robust approach is to use dynamic script insertion to append
script tag with src using x.com domain.

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

To automatically update, you can poll periodically.

Somebody else may be able to explain more about persistent connection,
but I'm guessing that what I wrote will be enough.

 

[johnwlockwood]

can anybody help me?

Mahdi, we were just talking about this in another thread. Sean Kinsey
has a library to help with this sort of thing easyXDM ( http://easyxdm.net/
)
If for site X.com, you cannot upload files to it's server, you can use
a bookmarklet to initiate the appropriate javascript. Sean just wrote
an example http://easyxdm.net/wp/2010/03/27/creating-a-bookmarklet-with-easyxdm/


also the FAQ for this group talks about cross domain scripting
http://jibbering.com/faq/#frameRef

 

[Thomas 'PointedEars' Lahn]

Mahdi, we were just talking about this in another thread.

What other thread are you talking about?

Sean Kinsey has a library to help with this sort of thing easyXDM [...]

I have looked at it, and what you are saying appears to be unlikely. For a
start, for this statement to have a chance to become true, he would need to
stop using features that are not universally available, and stop misusing
proprietary properties of host objects.

If for site X.com, you cannot upload files to it's server, you can use
a bookmarklet to initiate the appropriate javascript. Sean just wrote
an example [...]

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.


PointedEars

 

[Sean Kinsey]

I have looked at it, and what you are saying appears to be unlikely.  For a
start, for this statement to have a chance to become true, he would need to
stop using features that are not universally available, and stop misusing
proprietary properties of host objects.

If you are referring to the easyXDM library, could you elaborate on
this?
Why should it not use features that is not universally available when
it provides fallbacks where not, and which proprietary properties is
it misusing?

 

[Thomas 'PointedEars' Lahn]

If you are referring to the easyXDM library, could you elaborate on
this?
Why should it not use features that is not universally available when
it provides fallbacks where not,

Because the fallbacks constitute misuse. As a result, the approach is not
only not interoperable, it is also error-prone and not accessible.

and which proprietary properties is it misusing?

,-<http://easyxdm.net/wp/>
|
| [...]
| A bi-directional, reliable, secure and queueable Socket class that can
| transport strings between domains, using
|
| * HTML5 postMessage, or
| * window.name, or
^^^^^^^^^^^
| * hash/fragment
^^^^^^^^^^^^^

Your code is also full of common misconceptions like

easyXDM.js 2.0.1.77, line 222:
| if (name && window.attachEvent) {
| // Internet Explorer does not support setting the
| // name om DOMElements created in Javascript.
| // A workaround is to insert HTML and have the browser parse
| // and instantiate the element.


PointedEars

 

[Asen Bozhilov]

easyXDM.js 2.0.1.77, line 222:
|         if (name && window.attachEvent) {

^^^^^^^^^^^^^^^^^^
And that work properly in older versions of IE? If in older versions
they skip implement internal [[Get]] of host object, which refer
`attachEvent', that code will throw TypeError.

 

[Sean Kinsey]

and which proprietary properties is it misusing?

,-<http://easyxdm.net/wp/>
|
| [...]
| A bi-directional, reliable, secure and queueable Socket class that can
| transport strings between domains, using
|
|     * HTML5 postMessage, or
|     * window.name, or
        ^^^^^^^^^^^
|     * hash/fragment
        ^^^^^^^^^^^^^

And how exactly does this constitute misuse? And why do you say that
they are proprietary properties?
Both window.name and the hash part of the url are standard in the web
browser, and if you are trying to say that setting and getting a
string property on some object (its not even an expando property) is
_misuse_, then I do wonder what you consider proper use.

Your code is also full of common misconceptions like

easyXDM.js 2.0.1.77, line 222:
|         if (name && window.attachEvent) {
|            // Internet Explorer does not support setting the
|            // name om DOMElements created in Javascript.
|            // A workaround is to insert HTML and have the browser parse
|            // and instantiate the element.

Again, please explain. It is a fact that IE will not allow you to
change the name available to the program using Javascript.
http://msdn.microsoft.com/en-us/library/ms534184(VS.85).aspx

And whats with that negative attitude, seriously, talk about anal.

I have looked at it, and what you are saying appears to be unlikely. Fora
start, for this statement to have a chance to become true, he would need to
stop using features that are not universally available, and stop misusing
proprietary properties of host objects.

This perhaps the most stupid thing I have seen in your latest post. 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?

 

[Thomas 'PointedEars' Lahn]

^^^^^^^^^^^^^^^^^^
And that work properly in older versions of IE?

It works in standalone versions of IE 5.00.2614.3500, 5.50.4807.2300, and
6.0.2800.1106, but that says nothing about the feasibility of that approach,
of course.

If in older versions they skip implement internal [[Get]] of host object,

They cannot skip implementing it; they can only implement it differently.

which refer `attachEvent', that code will throw TypeError.

Yes, that host object's methods can be reliably feature-tested like this is
one of the many common misconceptions in that quoted piece of code alone.


PointedEars

 

[Sean Kinsey]

easyXDM.js 2.0.1.77, line 222:
|         if (name && window.attachEvent) {

                        ^^^^^^^^^^^^^^^^^^
And that work properly in older versions of IE? If in older versions
they skip implement internal [[Get]] of host object, which refer
`attachEvent', that code will throw TypeError.

Sorry for my simple browser detection, I'll make sure to introduce
more bloat as to properly support IE2 etc.
But seriously, I do appreciate the feedback, but maybe a bit more
pragmatic approach would be better suited?

 

[Thomas 'PointedEars' Lahn]

and which proprietary properties is it misusing?

,-<http://easyxdm.net/wp/>
|
| [...]
| A bi-directional, reliable, secure and queueable Socket class that can
| transport strings between domains, using
|
| * HTML5 postMessage, or
| * window.name, or
^^^^^^^^^^^
| * hash/fragment
^^^^^^^^^^^^^

And how exactly does this constitute misuse?

Those properties are not designed to do the things you want them to do.

And why do you say that they are proprietary properties?

There is no public standard to define them.

Both window.name and the hash part of the url are standard in the web
browser,

No, they are not. They have perhaps merely achieved the status of quasi-
standard by now. Still, it would be that quasi-standard status that
provides a basis for the recommendation against that which you are doing.

and if you are trying to say that setting and getting a
string property on some object (its not even an expando property) is
_misuse_, then I do wonder what you consider proper use.

An object has a property designed for a purpose. Storing data in its value
that does not correspond with that purpose obviously constitutes misuse.

Again, please explain. It is a fact that IE will not allow you to
change the name available to the program using Javascript.
http://msdn.microsoft.com/en-us/library/ms534184(VS.85).aspx

It does not apply to the `name' property of iframe objects.

And whats with that negative attitude, seriously, talk about anal.

The usual script-kiddie response.

This perhaps the most stupid thing I have seen in your latest post.

But it was in my next-to-latest posting instead. Learn to quote.

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.

Please change your attitude or go away.


PointedEars

 

[Asen Bozhilov]

Asen Bozhilov wrote:

If in older versions they skip implement internal [[Get]] of host object,

They cannot skip implementing it; they can only implement it differently.

That is correct regarding ECMA-262 standard, but IE doesn't follow
that point. There are examples with host objects, which don't have
internal [[Get]] method.

e.g.

try {
new ActiveXObject('Microsoft.XMLHTTP').open;
}catch(e) {
window.alert(e instanceof TypeError); //true
}

 

[Thomas 'PointedEars' Lahn]

If in older versions they skip implement internal [[Get]] of host
object,

They cannot skip implementing it; they can only implement it
differently.

That is correct regarding ECMA-262 standard, but IE doesn't follow
that point. There are examples with host objects, which don't have
internal [[Get]] method.

You are mistaken.

e.g.

try {
new ActiveXObject('Microsoft.XMLHTTP').open;
}catch(e) {
window.alert(e instanceof TypeError); //true
}

Your example does not support your argument. Implementing a method
differently than specified includes throwing any exception when it is
called.


PointedEars

 

[Sean Kinsey]

Those properties are not designed to do the things you want them to do.

That might be, but the hammer, designed to hit nails, still work
perfectly for breaking tiles as it makes use of the primary property
of the hammer, the ability to build up, store, and transfer kinetic
energy.

There is no public standard to define them.


No, they are not.  They have perhaps merely achieved the status of quasi-
standard by now.  Still, it would be that quasi-standard status that
provides a basis for the recommendation against that which you are doing.

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.

An object has a property designed for a purpose.  Storing data in its value
that does not correspond with that purpose obviously constitutes misuse.

Misuse with regard to its intention maybe, but not a use that brings
any negative effect. Again, the hammer and the nail.

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.

The usual script-kiddie response.

No, that is the response of a pragmatist.

But it was in my next-to-latest posting instead.  Learn to quote.

Will do

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, in
fact, its an observable truth that it _does_ work in the target
browsers.

 

[Thomas 'PointedEars' Lahn]

easyXDM.js 2.0.1.77, line 222:
| if (name && window.attachEvent) {

^^^^^^^^^^^^^^^^^^
And that work properly in older versions of IE? If in older versions
they skip implement internal [[Get]] of host object, which refer
`attachEvent', that code will throw TypeError.

Sorry for my simple browser detection, I'll make sure to introduce
more bloat as to properly support IE2 etc.

Argument at ridicule. If you knew what you are talking about, you would
know that IE 2 did not support scripting to begin with; JScript 1.0 was
introduced with version 3.0. You would know that it is not so much a
matter of IE as of MSHTML, and that host objects are so special that, as
Lasse Reichstein Nielsen once put it so aptly here, "with host objects, all
bets are off."

But seriously, I do appreciate the feedback,

No, unfortunately you don't. Or you would have reacted very differently.

but maybe a bit more pragmatic approach would be better suited?

Yes, it would. Why do you keep living in and designing for a fantasy world
instead?


PointedEars

 

[Asen Bozhilov]

Asen Bozhilov wrote:

Your example does not support your argument.  Implementing a method
differently than specified includes throwing any exception when it is
called.

Yes yes, i was mistaken. They just implement in other way.
With follow example that can observe:

var xhr = new ActiveXObject('Microsoft.XMLHTTP');
window.alert(xhr.readyState);

Thanks for corrections.

 

[Thomas 'PointedEars' Lahn]

Sean Kinsey wrote:

[attribution restored]

[Thomas 'PointedEars' Lahn wrote:]

Those properties are not designed to do the things you want them to do.

That might be, but the hammer, designed to hit nails, still work
perfectly for breaking tiles as it makes use of the primary property
of the hammer, the ability to build up, store, and transfer kinetic
energy.

I find your argument strewn with gaping defects in logic.

OK, fine, I'm not an expert on the spec,

Yet you pose as being one. What does that tell you about the quality of
your "knowledge"?

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.

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.

An assumption not supported by the available facts, of course.

Misuse with regard to its intention maybe, but not a use that brings
any negative effect. Again, the hammer and the nail.

To use that metaphor, you know only a *subset* of *current* nails.

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.

No, that is the response of a pragmatist.

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.

Will do

You better really do it.

Well I do expect it to work reliably on all the target browser,

There is your problem.

in fact, its an observable truth that it _does_ work in the target
browsers.

How many combinations of data have you tested?


PointedEars

 

[Thomas 'PointedEars' Lahn]

Yes yes, i was mistaken. They just implement in other way.
With follow example that can observe:

var xhr = new ActiveXObject('Microsoft.XMLHTTP');
window.alert(xhr.readyState);

I see your verbal concession, but what is this code supposed to prove?

Thanks for corrections.

You're welcome.


PointedEars

 

[Asen Bozhilov]

I see your verbal concession, but what is this code supposed to prove?

I like the truth, I'm not so headstrong especially when i saw my
mistakes
It prove your words about special [[Get]] of that object and disaprove
my theory for non-existing [[Get]] method. However, thanks for pointed
out that.

 

[Sean Kinsey]

[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.

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?

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.

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.

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.

You better really do it.


There is your problem.

A useless comment as my expectations are based on observable facts

How many combinations of data have you tested?

All the relevant ones.