Hi, again! First of all, I would like to thank everyone for their quick and informative responses and a special 'Thank you!' to Derrell for the excellent information on the PHP RPC. Got the RPC working beautifully, thank you!
Encouraged by your responses, I have been playing around with qooxdoo now for a bit and, while I have figured out some things, others are becoming more of a stumbling block than I thought before. To summarize, rewriting the XRMS UI in qooxdoo is simply not an option. XRMS is not a trivial application. We are talking about 90MB of PHP code! The idea was, for now, to use qooxdoo to extend the XRMS UI by adding additional rendering and functionality. I figured out that qooxdoo has to be setup as an Inline Application so it can overlay the existing XRMS UI (using popup windows, etc.). So far so good. Now, with a more practical, question... In many places of the XRMS UI, there are listings of activities, presently rendered by XRMS in a standard HTML table. I can manipulate the rows of the table in PHP and have the code output a link on each activity row with the activity_id provided in the link, something like: More Info The idea was to have the custom.js.method then communicate via the RPC with a server PHP method, passing the activity_id to that and get as a response additional information about the activity which can be rendered in a qooxdoo widget like a popup window. It sounds good like an idea but I had a problem even launching the demo application from such a link... Is this at all possible? Could anyone give me some ideas on how to implement that if it is at all something that can be done? Thank you all for your help! Cheers, Ivaylo Derrell Lipman wrote: > > On Wed, May 6, 2009 at 1:32 PM, ITgopher <[email protected]> wrote: > >> >> Hi, Everyone! >> > > Hello Ivaylo! > > >> The idea is to do all data access/processing within XRMS, exclusively in >> PHP, due to the extensive and solid work that has gone into XRMS's API >> (ACL, sessions, etc.) and then pass the data to qooxdoo's interface to >> render it sweetly for the user. My understanding was that I would simply >> be >> using the qooxdoo's widgets to do the rendering of data and collecting >> user >> input after which I could simply pass that back to PHP and use the XRMS >> API >> to store/process the newly supplied inputs. >> > > Your proposed methodology should be fine. As someone else mentioned, you > can > get some nice benefits of distribution of work by moving some or much of > the > processing from the server to the client (thus your server, responding to > possibly many clients, has much less work to do on behalf of all of the > clients). Your project may not lend itself to that, though, so what you > are > proposing to do should be a fine way to move forward. > > >> I got "Hello World" working, no problem. I got the PhpRpc server setup >> and >> got RPCExample working and, at least the Echo Test works (I will look at >> the >> rest later today 'cause something seemed fishy). >> > > Good. You're on your way. The thing that looks fishy is probably the > "Application Error 23" at the end. That's testing the ability to have the > backend throw an error that gets returned to the frontend, and is a > correct > response to the final (I think) test in the test suite. > > >> Here is my question? Considering that I am not JS expert by a long shot, >> just how complicated would it be to use qooxdoo to acomplish the task I >> have >> envisioned? Configuring the UI widgets did not seem to be quite so >> complicated and I think I can manage that. What stumps me is the PhpRpc. >> I >> have had spotty success in gathering information about it - the wiki doc >> is >> most likely a bit outdated and I had to piece together what I needed to >> get >> RPC Example from some of the posts here (modifying config.json and using >> the >> core qooxdoo generator.py instead of the RPCExample generate.py) > > > I suspect that the problem is that generate.py needs to know the qooxdoo > framework path. It probably makes sense for the generate.py script to look > in config.json for that path, but currently it doesn't. I'll talk to > Thomas > about this. You must have corrected the path in config.json, so please > take > a look at generate.py and fix the path there too, and let me know if that > solves your problem with running the generator. > >> >> I seemed to notice that the PhpRpc is a shiny new release and there is >> still >> work going into it > > > Yup. Christian took my original server and converted it to be much more > object oriented. My original version in 1.0.0 is well tested at this > point. > Christian's version in trunk is known to work for him, but has had little > outside testing yet AFAIK. The trunk version is supposed to be backward > compatible with 1.0.0 as far as the RPC method implementations go, so > moving > from 1.0.0 to trunk (or back again) should be a no-brainer. > > >> but I was wondering if there is some more organised >> information on its use, how to pass data back and forth to the PHP >> script, >> etc. I am just a bit lost at the moment and don't know where to start >> looking. Any help would be appreciated. > > > How to pass the data from the client (qooxdoo) side is documented in > qx.io.remote.Rpc, and demonstrated in RpcExample. There are three ways to > issue a remote procedure call: synchronously (qx.io.remote.Rpc.callSync -- > dangerous because it blocks the whole browser, not just your application, > so > is highly discouraged); async with results via a callback function > (qx.io.remote.Rpc.callAsync) and async with results via an event listener > (qx.io.remote.Rpc.callAsyncListeners). Each of these is documented in the > API viewer at http://demo.qooxdoo.org/current/apiviewer/#qx.io.remote.Rpc > > To understand writing RPC method implementations for the PHP backend, take > a > look at > qooxdoo-contrib/trunk/qooxdoo-contrib/RpcPhp/1.0.0/services/qooxdoo/test.php. > You'll see that each method function takes two parameters. The first, > $params, is an array of the parameters passed by the client. The second > parameter is an error object which should be set, using its SetError() > method, if an exception occurs while attempting to process the request. If > the request processing completes normally, the actual result object is > returned. If an exception occurred, then the error object (which has now > had > an error specified by a call to SetError()) is returned. > > You may also find the server writer's guide helpful: > http://qooxdoo.org/documentation/Rpc_server_writer_guide > > >> Of course, if, after reading the above, you feel that I am trying to >> scoop >> water out of a quickly sinking boat with a spoon, please let me know >> before >> I join the fishes ;) > > > As long as you're not scared of learning a new language and you feel that > you'll come up to speed with it reasonably quickly, I think you'll find a > bucket with which to bail until the chewing gum has been chewed soft > enough > to patch the hole. :-) > > Cheers, > > Derrell > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- View this message in context: http://www.nabble.com/Am-I-up-the-creek-without-a-paddle--tp23411770p23553649.html Sent from the qooxdoo-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
