Just for the record: We have been using Qooxdoo's RPC for communication with the server backend (Perl) for several years now using either RpcPerl Classic or RpcPerl with Mojolicious (see http://qooxdoo.org/contrib/project) very sucessfully for various projects. I don't understand why that is considered "absurd" or "complicated".
Some of my bachelor students also managed to get this working with an RpcPhp backend (I don't do Php if I can avoid it). Cheers, Fritz On Thu, 11 Oct 2012, jwhitten wrote: > > Well, I definitely agree that it seems quite a bit over the top in terms of > effort just to get data to the back-end. The js / qooxdoo side is nearly > verbatim from some example I found on the net. All I did was modify it a > little with try/catch blocks and added some debug messages to see what was > happening. > > The back-end is about as plain-jane RPC as you can get. I've got two servers > I've written, one in Perl, the other in PHP which toss RPC pretty > generically. I think I wrote them some months back when I was testing > various JS / Ajax frameworks. They've just always worked with very little > tinkering. I wrote another one out of CPAN parts more recently that's even > more generic-- JSON::RPC::Dispatcher. > > (shrug) :-) > > All my own JS code in the past has been trivial. This really seemed.. not > sure how to even describe it-- somewhere between frustrating and absurd! :-) > Had even been considering ditching Qooxdoo for something else. The > documentation for the thing seems to alternate between pretty good and > just-barely. I spend a lot of my time just trying to figure out what they're > doing in places or compensating for something that doesn't seem to be there. > > I realize that it's an evolving effort. And I'm not meaning to knock > anybody's efforts in any way-- you know, I'm pretty happy and thrilled at > having a cool, open source toolkit to work with. But its a lot different > than many of the GUI paradigms I've used in the past with other languages, I > can certainly say that! > > Anyway-- if you know of an easier way-- heh, I'm all ears!! I'd love to look > at some "well-built" Qooxdoo apps for style and best-practice tips & > pointers. I'm just kind of feeling my way along trying to get a feel for it. > > > John > > > > -- > View this message in context: > http://qooxdoo.678.n2.nabble.com/Need-help-with-Models-please-tp7581630p7581660.html > Sent from the qooxdoo mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- Oetiker+Partner AG tel: +41 62 775 9903 (direct) Fritz Zaucker +41 62 775 9900 (switch board) Aarweg 15 +41 79 675 0630 (mobile) CH-4600 Olten fax: +41 62 775 9905 Schweiz web: www.oetiker.ch ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
