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
