Getting & Sending XML objects--Flash or JavaScript? Options

[bspachman]

I've dived into the deep end in starting to work on my first widget.

The problem I'm banging my head against is that I need to query a server whose response will return an XML document to me. I'm willing to write the parser I need (until K gives us access to its own parser), but I cannot even retrieve the appropriate object.

I believe I need to send something like:

CODE

xmlhttp = new XMLHttpRequest();

xmlhttp.open("GET", "192.168.123.133:8080",true);

or something like:

CODE

xmlhttp=new ActiveXObject("Microsoft.XMLHTTP")

xmlhttp.open("GET", "192.168.123.133:8080",true);

but I get an error in my debug window when using these statements. The error is: "Global/OnLoad:5: ReferenceError: XMLHttpRequest is not defined"

I have a working example of what I'm trying to do--but it's written as a Flash object, using lots of ActionScript.

An example of the ActionScript construct for initialization is:

CODE

socket.send(new XML ("<?xml version='1.0'?>rn<REQUEST command='initialize' value=''/>rnrn"));

So...is there currently any way to replicate a "socket" ActionScript command or perform "XMLHttpRequest" in a way that K will understand?

Best,
Brad

[Arlo Rose]

Have you had a peak at our reference guide? We don't support doing either of those examples above.

You might want to use a combo of CURL and runCommand.


Cheers,
Arlo Rose

[bspachman]

Have you had a peek at our reference guide?  We don't support doing either of those examples above.

Arlo,

Thanks for the response. I've seen the documentation--the only method built into K appears to be "URL.fetch".

I'm quite a newbie when it comes to this...I'm not even up to speed on what the ActionScript example does. I'm only knowledgable enough to be a little dangerous--hence my question & need for a work-around

You might want to use a combo of CURL and runCommand.

Right...the CURL command looks fiendishly complicated. I found this in the documentation:

CODE

What about SOAP, WebDAV, XML-RPC or similar protocols over HTTP?



Curl adheres to the HTTP spec, which basically means you can play with *any* protocol that is built on top of HTTP. Protocols such as SOAP, WEBDAV and XML-RPC are all such ones. You can use -X to set custom requests and -H to set custom headers (or replace internally generated ones).

I'm assuming both the "X" and "H" switches for curl are going to be important to me. Any pointers on how to decipher this to accomplish my task?

Best,
Brad

[blalor]

Arlo,
Thanks for the response. I've seen the documentation--the only method built into K appears to be "URL.fetch".

[ ... snip ... ]

I'm assuming both the "X" and "H" switches for curl are going to be important to me. Any pointers on how to decipher this to accomplish my task?

I'm fairly shocked to see nobody else clamoring for XMLHttpRequest. I want to write some (cross-platform) web service-enabled widgets, but I don't stand a snowball's chance doing it with just URL.fetch; there just isn't enough control over the request. Without the ability to set additional headers and POST data, I can't do SOAP or XML-RPC, or anything else that requires *real* communication with a server. REST only takes you so far, and I don't feel that I should have to write, maintain, and make available a server-based entity to proxy requests for K.

Why are we still waiting for a native XML parser and first-class HTTP support in a product actively being developed in 2005?

[Lars1024]

Harsh words, blalor. Personally, I have always regarded the idea and design of the Konfabulator API to first and foremost be easy to grasp for non-professionals, and not primarily intended to give skilled programmers a fully-fledged development framework.

The API evolves over time and it's probably quite possible that we will see a built in XML parser and perhaps something in the lines of JavaScript XMLHttpRequest or a more powerful URL object in the future. But I believe it's a good thing if Perry & co. keeps balancing new features with continued ease of understanding the code in widgets, so that Konfabulator won't alienate skilled programmers or scripting rookies.

[blalor]

Harsh words, blalor. Personally, I have always regarded the idea and design of the Konfabulator API to first and foremost be easy to grasp for non-professionals, and not primarily intended to give skilled programmers a fully-fledged development framework.

Then what's the point? There's a limit to what you can do without consuming data, and Konfabulator isn't providing the tools to consume the data. Powerful frameworks don't negate ease of use. JavaScript already has a low entry threshold. There are dozens of books and websites dedicated to showing folks with limited programming chops how to develop powerful, interactive software. It's great that K allows people to make widgets that sing, dance, pulse and glow, but now it's time to enhance things a bit.

The API evolves over time and it's probably quite possible that we will see a built in XML parser and perhaps something in the lines of JavaScript XMLHttpRequest or a more powerful URL object in the future. But I believe it's a good thing if Perry & co. keeps balancing new features with continued ease of understanding the code in widgets, so that Konfabulator won't alienate skilled programmers or scripting rookies.

Eh? "Let's dumb it down for the newbies?" That just doesn't fly. How does not providing robust, high-performance capabilities of the JavaScript engine make code easier to read? This thread is TWO YEARS old! How much more time is needed to provide these features? Without them, they might as well just close up the Mac side of the business and concentrate on the Windows side, because Tiger will provide these capabilities RSN.

Konfabulator is a great start, but I haven't seen much in the way of innovation since Windows support came to town.

[Jools]

have you checked out http://xmljs.sourceforge.net/ for the javascript help on decoding XML natively, I haven't tried using openURL or url.fetch for non port 80 addresses, but have you tried something along the lines of :

CODE

contents = url.fetch("http://192.168.123.133:8080/")

I'd guess that using that with some javascript XML processing would solve the problem you've currently got.

There are quite a few XML processing scripts out there that are fairly easy to use.

[blalor]

have you checked out http://xmljs.sourceforge.net/ for the javascript help on decoding XML natively,

Yes, I have seen and used it. It's quite good, in fact (lest folks here think I have *nothing* positive to say... ). Unfortunately, there's still no way to POST data to a remote host or manipulate headers. Both are required, at least in part, to have XML-RPC and SOAP implementations. XMLJS also claims to be a "parser" and not a "generator", but I haven't verified that. If it can't generate XML, then you're left to doing it by hand.

[Jools]

Unfortunately, there's still no way to POST data to a remote host or manipulate headers.

Ah, I see - I didn't know it was the post that was causing the problem. Have you tried using

CODE

curl -d

or

CODE

curl --data

[blalor]

Ah, I see - I didn't know it was the post that was causing the problem.  Have you tried using 

CODE

curl -d

or

CODE

curl --data

No; that's really pretty kludgy, IMO, and also not cross-platform. I think K should provide that functionality.

What I will do, if I decide to persue anything that requires XML-RPC or SOAP, is use Python. Still not x-plat, but sooo easy to code.

[Jools]

No; that's really pretty kludgy, IMO, and also not cross-platform.  I think K should provide that functionality.

What I will do, if I decide to persue anything that requires XML-RPC or SOAP, is use Python.  Still not x-plat, but sooo easy to code.

curl is provided for both platforms, and therefore it is cross-platform. I believe that there may be a problem with the ssl libraries in the windows one, but as long as you're using http and not https, there should be no problem.

Would it be more useful if it was supported in K - yes. Is it necessary - nope, IMHO there at a lot of other things that could be added first (including simple socket access).

[dcarroll]

curl is provided for both platforms, and therefore it is cross-platform.  I believe that there may be a problem with the ssl libraries in the windows one, but as long as you're using http and not https, there should be no problem. 

Would it be more useful if it was supported in K - yes.  Is it necessary - nope, IMHO there at a lot of other things that could be added first (including simple socket access).

With more web services and SOA applications coming to market, the need for XMLHttpRequest as grown. Having a lightweight widget that can com with the hosted application is huge.

Please consider this enhancement. Please?

I would love to create widget after widget for the sforce web service and demo these at every one of our events, but... no SOAP.

[Arlo Rose]

SOAP and XML-RPC are on our roadmap. Can't tell you when they'll show up though... but hopefully sooner rather than later.


Arlo

[dcarroll]

SOAP and XML-RPC are on our roadmap.  Can't tell you when they'll show up though... but hopefully sooner rather than later.
Arlo

That's great to hear, and thanks for a timely response. I'll be here waiting patiently. I understand roadmaps and releases and committments, but it's great to know that you have non-rest web services in mind.

Thanks!