<<< Mastering Ext.Direct, Part 1

Adding server-side classes

After completing part 1, we have the basic setup running. Although Ext.Direct PHP stack example classes are fine for demonstrating the functionality we will need our own PHP classes in the real life. I’m not going to explain basics of PHP object oriented programming, anyway, there is a couple of things to point out.

Let’s create (useless) class Car from part1. For that, create file classes/Car.php with the following content:

Then edit api.php and add Car to $api->add() call so that it reads:

Reload index.php and type in Firebug console:

You should get the following response:

Now type:

Error, yes? Why? Take a deeper look at Car source code. Some methods have comments

but repair does not have it. And that is the single reason why it is not exported to API so it is not known to the client application. You can verify it by typing:

in Firebug console.

If you want to know how is it done study ExtDirect_API PHP class in classes/API.php file and ReflectionClass documentation. In any case, it makes our life very easy as we only need to:

• write server side classes
• add the above comment to the methods that can be called remotely

Can it be simpler?

Returning values

Type in Firebug console:

Now you see that the return value of the call is undefined despite of the fact that server side method returns string "Started". This leads us to a very important note:

Ext.Direct calls are ASYNCHRONOUS.

That means that the code execution does NOT wait until the call is finished but it immediately continues. So never try to use the return value, neither assume that you have data available at the line that follows the call.

The value returned from the server side method call is wrapped in the request response and it arrives when it arrives. It can take milliseconds or seconds depending on the connection speed, server execution time and other factors.

I will discuss response processing in the next part

Exceptions

Edit go method of our Car class so that it reads:

and execute:

You get the following response:

You see that the response type changed from rpc (remote procedure call) to exception and the response contains member message that is the text of the Exception we’ve thrown at server side. So far so good, however, where member contains debugging data that, while useful for debugging, shouldn’t be disclosed in a production environment.

You can freely throw exceptions while debugging your Ext.Direct application but you should consider another method(s) of handling errors for production systems. I will tackle it again later in this series.

Combining requests

Type the following:

The request is:

and the response is:

Ext.Direct combines requests that come within a configurable time frame into one to minimize the server round trips count.

Conclusion

Now we know a couple of basics:

• we need to export API from server to client – Ext.Direct stack does a lot of dirty work for us
• we can call server side methods directly at client prefixed with a configurable namespace (Example in our case)
• we cannot use return values of client calls because calls are asynchronous
• to add classes we need to add them to $api->add() call and add /** @remotable */ comments to methods
• multiple requests and responses are combined in one if they come fast enough

Mastering Ext.Direct, Part 3 >>>

• About
• Latest Posts

Follow me:

saki

I'm a well seasoned developer, consultant and educator of web applications based mainly on Sencha libraries, PHP, MySQL and Node.js. Besides (Apple) computers, I love photography and mountain biking.

Follow me:

Latest posts by saki (see all)

• Ext, Angular, React, and Vue - June 27, 2019
• The Site Resurgence - February 11, 2018
• Configuring ViewModel Hierarchy - June 19, 2015