I really have been gaining a lot of new perspective on the state of things
on the web,
WebSockets let me make an almost immediate and trouble free connection
between Qooxdoo and EventMachine hosting much of my years of work in the way
of a "Class Server". More about that if there is interest - but it does
some stuff I think is pretty "cool" and useful in a very general way....
Anyway, as I had things working nicely with formatted queries in JSON, and
responses coming back I could concentrate on building up the interface. The
WebSockets just worked, NOTHING but NOTHING else would work - and I was
trying everything for a couple of solid days. Clues here, clues there but
no one thing made it work. A helpful response on this forum hinted at the
underlying issue of what is coded out as: "Access-Control-Allow-Origin" -
or basically for security reasons, we are going to complicate your life. :)
So, we are ready to deploy this early version we have and see what some
people think and I went to the "Pusher" folks in London where I thought they
had a WebService and find out, as far as I could determine, there is a
service but it does NOT include hosting applications. As I googled and
googled on the whole matter, and responses came back I began to understand,
what one blogger said about these things: "They are the 'flying cars' of
the Web"
.... jury is out on that so to say, the London "Pusher" folks might be able
to steer me to a hosting company just right for our needs, but I needed to
march on and see if I could establish something like "HTTP" level
request/response using popular, accepted, known tools like the Sinatra web
framework based Rack and Thin.
To keep the story short, after several days now of just trying everything I
have finally found the right combination to bypass all the traps for local
development. Here goes:
1. Chrome can be called with a --Access-Control-Allow-Origin command line
param that doesn't seem to do anything. Not even
sure if it was necessary yet.
2. I tried a whole bunch of things into the config & manifest .json files,
in the end I'm also not sure what helped but I landed with
this combination:
"Access-Control-Allow-Origin:
http://localhost:4567/?qxenv:qx.debug.io:true";,
3. BUT what I DO KNOW is that I had to add the "magic incantation of":
*response['Access-Control-Allow-Origin'] = "*"* - to each
block of code so that a "response" block looks like this:
get '/helloworld' do
response['Access-Control-Allow-Origin'] = "*"
"Happy Halloween George!, this is Franky responding from the other
side..."
end
4. Still nothing was working until I found a really small Library of Ajax
tools called Open JX (this is after trying MooTools, JQuery and many more
but before I established some of the above, particularly #3). I used the
"lite" version which is about 65 lines full of comments! (versus about
7,000 for JQuery - which is a poor fit, I will guess, with a lot of overlap
with Qooxdoo.
It can be found here: http://www.openjs.com/scripts/jx/jx.php
AND they have a really, IMHO, brilliant Demo / Tester screen where you can
try their code live with what ever app you are working with! Makes testing
much easier/faster! Plus if it works you have the exact code you need in
your program (to start with anyway).
YEAAAAA!
The article I found with this fix did not put quotes around the * - I
thought it "odd" but used it literally as he published it.
WELL - that was the final "TRick" - and now I have established contact with
this "Class Server" thing of ours.
For anybody interested, I am more convinced than ever that Ruby was the
right language for the back-end stuff. JavaScript takes about 2X as many
lines to do anything, and its just ugly and boring, and way too full of
critical commas, brackets, parans, and semi-colons! I just spent, last
month, a solid 2 weeks working in C# and I swear every other line is
involved with keeping their "strict typing" that the language seems to be
getting painfully backed out of.
The interface "Form" / program I am, myself, authoring will run about 3,000
lines and will, for example, support "vocabulary extraction" from these
"ClassBases" to make it easy for about anybody, about anywhere, to add
computer natural language as well as computer usable information into these
things. I can't believe how "general" the utility seems to be. We are
looking to use them for making "interactive manuals" but I believe they have
a much wider potential use.
Happy Halloween Folks!
George K
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Qooxdoo-talking-to-Sinatra-Sinatra-talking-back-finally-and-more-on-WebSockets-tp6947700p6947700.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
