How to parse xml in JS
Piotr Maslak
how to get information from xml (giving url) and
then format and print with JS with interval
Thanks for a tip.
PM
VK
> Hello everyone, I looking for a gently solution
> how to get information from xml (giving url) and
> then format and print with JS with interval
You cannot work with data across different domains. There are
different ways to use different auxiliary transports for cross-domain
XML data transfer (Web Services, Runtime Script Blocks, JSONet) - but
they are rather or very far from anything being "gently" :-)
For the same domain data exchange I would suggest AjaxToolBox
http://www.ajaxtoolbox.com
Bart Van der Donck
> On Nov 20, 9:21 pm, "Piotr Maslak" <piotr.mas...@wp.pl> wrote:
>
>> Hello everyone, I looking for a gently solution
>> how to get information from xml (giving url) and
>> then format and print with JS with interval
>
> You cannot work with data across different domains. There are
> different ways to use different auxiliary transports for cross-domain
> XML data transfer (Web Services, Runtime Script Blocks, JSONet) - but
> they are rather or very far from anything being "gently" :-)
What an odd opinion. I would say the direct opposite. It are server-
side XML scripts that open the real possibilities, not XMLHttpRequest.
Virtually any server side language is able to make remote requests
(typically using sockets, but I've also used plain HTTP, ot whatever
channel that both parties understand). Most of the server languages
also have XML parsers. From the point you have those two tools (remote
requests + XML parser), the sky is the limit.
I think Douglas Crockford is very right to propose his JSONRequest,
which could hopefully stop the XMLHttpRequest hype one day.
--
Bart
VK
> VK wrote:
> > On Nov 20, 9:21 pm, "Piotr Maslak" <piotr.mas...@wp.pl> wrote:
>
> >> Hello everyone, I looking for a gently solution
> >> how to get information from xml (giving url) and
> >> then format and print with JS with interval
>
> > You cannot work with data across different domains. There are
> > different ways to use different auxiliary transports for cross-domain
> > XML data transfer (Web Services, Runtime Script Blocks, JSONet) - but
> > they are rather or very far from anything being "gently" :-)
>
> What an odd opinion.
What is odd in here? That JavaScript cannot operate (by default)
across domains? The OP question was about possible JS solutions, not
just about any possible solution. ;-)
> It are server-
> side XML scripts that open the real possibilities, not XMLHttpRequest.
> Virtually any server side language is able to make remote requests
> (typically using sockets, but I've also used plain HTTP, ot whatever
> channel that both parties understand). Most of the server languages
> also have XML parsers. From the point you have those two tools (remote
> requests + XML parser), the sky is the limit.
Yes, and doubled Internet traffic worldwide ;-) :-(
With client-side cross-domain handling we have:
Client <--> Server A
^-- <--> Server B
With any of content-grabbers we have:
Client
Client <--> Server A
^-- <--> Server A <--> Server B
So on each such call one has one absolutely "no added value" data
transfer.
Think of it as of a real standard and think of pentabytes of useless
data transfers across the Internet.
So no, my opinion is that server-side content-grabbers is a temporary
forced measure caused by stubbornness of UA producers (they kept
believing that it adds any security to their clients). The future is
for Web Services and server-side access permission files (WSDL).
Bart Van der Donck
> With client-side cross-domain handling we have:
>
> Client <--> Server A
> ^-- <--> Server B
>
> With any of content-grabbers we have:
>
> Client
> Client <--> Server A
> ^-- <--> Server A <--> Server B
>
> So on each such call one has one absolutely "no added value" data
> transfer.
I'm sorry ? I would say the added value is quite obvious, namely "use
their data". But IMHO your scheme is only one part of the story. I
have much more experience with the following flux:
Server A <--> Server B (e.g. nightly database updates)
And then, for the daily needs:
Client <--> Server A
> Think of it as of a real standard and think of pentabytes of useless
> data transfers across the Internet.
I wouldn't call remote requests "useless data transfers" :-) It all
depends on what you want.
> So no, my opinion is that server-side content-grabbers is a temporary
> forced measure caused by stubbornness of UA producers (they kept
> believing that it adds any security to their clients).
I don't agree. I think they are very valuable, and that this kind of
communication will keep existing for a very long time to come. Even if
it were only to populate a database automatically or for middleware
systems. The benefits are just too numerous.
> The future is for Web Services and server-side access permission
> files (WSDL).
Yes, something like that would probably have a great future for client
scripting.
--
Bart
Piotr Maslak
hidden textarea.
VK
> > forced measure caused by stubbornness of UA producers (they kept
> > believing that it adds any security to their clients).
>
> I don't agree. I think they are very valuable, and that this kind of
> communication will keep existing for a very long time to come. Even if
> it were only to populate a database automatically or for middleware
> systems. The benefits are just too numerous.
>
> > The future is for Web Services and server-side access permission
> > files (WSDL).
>
> Yes, something like that would probably have a great future for client
> scripting.
domo arigato
VK