2

I'm trying to get a grip on Ext.direct. On the official page there is this description of the API:

The purpose of the API component of the Ext Direct stack is to output the method configurations for Ext Direct to create client-side stubs. By generating these proxy methods, we can seamlessly call server-side methods as if they were client-side methods without worrying about the interactions between the client and server-side.

I just don't quite get what it means by ...to output the method configurations for Ext Direct to create client-side stubs. Would someone care to explain what this means at a grassroots level?

mr_js
  • 949
  • 12
  • 29
  • Perhaps seeing an example will help. Go here: http://docs.sencha.com/extjs/4.2.2/extjs-build/examples/direct/direct.html, view the page source and view `api.php`. That's the output the server is expected to produce. – Evan Trimboli Jan 28 '14 at 20:34

1 Answers1

1

This will make more sense if you look at the output from the api.php resource included in the following example.

Note that this is being loaded on the page as a <script/> tag, ie:

<script type="text/javascript" src="php/api.php"></script>

When you open the src link you'll see the following JavaScript being generated by server-side PHP (see block of javascript code below).

In other words, PHP is doing the bit where it ... output(s) the method configurations for Ext Direct to create client-side (ie JavaScript) stubs.

Now the next question you should be asking if you want to make sense of this is: Why bother generating client side JavaScript using server side PHP (or other language of choice)?.

Ext.ns("Ext.app");
Ext.app.REMOTING_API={
    "url": "php\/router.php",
    "type": "remoting",
    "actions": {
        "TestAction": [{
                "name": "doEcho",
                "len": 1
            }, {
                "name": "multiply",
                "len": 1
            }, {
                "name": "getTree",
                "len": 1
            }, {
                "name": "getGrid",
                "len": 1
            }, {
                "name": "showDetails",
                "params": [
                    "firstName",
                    "lastName",
                    "age"
                ]
            }],
        "Profile": [{
                "name": "getBasicInfo",
                "len": 2
            }, {
                "name": "getPhoneInfo",
                "len": 1
            }, {
                "name": "getLocationInfo",
                "len": 1
            }, {
                "name": "updateBasicInfo",
                "len": 0,
                "formHandler": true
            }]
    }
};

This seems to be mimicking the way a WSDL works in that it can provide a service description and list all the options available for quering. In other words: Ext.Direct API is taking a concept from SOAP and applying it to a Javascript setting.

The back-end contains the API so this is the easiest place to generate a service definition with all the method names and signatures. Once the Ext.Direct API method stubs are provided (in the back-end), the front-end Ext.Direct library will do the plumbing and turn these into actual functionality that can be queried and used in JavaScript. Much in the same way as SOAP proxy classes can be automatically generated (in PHP/C# or Java) using the WSDL.

Personally I think this is a bit too airy-fairy for my liking. Most APIs are pretty straight forward and trying to implement something akin to WSDL actually makes consumption a lot harder than it would be if you just talk to it directly.

Community
  • 1
  • 1
Steven de Salas
  • 20,944
  • 9
  • 74
  • 82
  • Thanks. I think I get it now. Please correct me if I am wrong: The api component of the server stack generates the method configurations for the client side stubs. Then ext.direct on the client side automatically generates the stubs from these configurations. – mr_js Jan 29 '14 at 13:49
  • Correct, I'll update the question further to make this point clear. – Steven de Salas Jan 29 '14 at 22:54