Ext JS 3.0 – Remoting for Everyone
As developers, we spend countless hours researching best practices to build engaging software. Often we find ourselves implementing the same repetitive functionality to wire our frontend to our backend. We’ve become accustomed to partaking in complicated design patterns to help separate logic from presentation – forcing the browser to play the role of a dumb terminal. While the RIA movement has unshackled the web browser from that awful fate, accessing our server side logic remains mostly unchanged. Ext.Direct aims to solve this issue for developers creating Ext JS applications by providing a single communication point with the server-side.
Common Concerns
At Ext, we’ve integrated Ext JS with many languages and platforms from Mainframe systems to Java to MUMPS to Perl. However, we noticed that there are several issues that are common across all server-side languages when creating Ext apps.
- How to organize code and where to place appropriate business logic.
- Parsing and formatting data on the server side.
- Keeping a maintainable structure.
- Parsing Ajax responses and retrieving error conditions.
- Doing data validation in multiple areas.
Wouldn’t it be nice if we had a cross-language standard that solved the problem the same way?
Introducing Ext.Direct
Ext.Direct is a new package in Ext JS 3.0 that helps alleviate many of these issues by streamlining communication between your client and server. When using Ext.Direct, you can expect to write 30% less code by eliminating common boiler plate code.
The Ext.direct namespace introduces several new classes for a close integration with the server-side. New classes have also been added to the Ext.data namespace for working with Ext.data.Stores which are backed by data from an Ext.Direct method.
Ext.Direct uses a provider architecture, where one or more providers are used to transport data to and from the server. There are several providers that exist in the core at the moment, for example a JsonProvider for simple JSON operations and a PollingProvider for repeated requests. One of the most powerful providers is the RemotingProvider.
RemotingProvider – Client-side Stubs
The RemotingProvider empowers the developer by mirroring server side methods on the client-side and allowing them to call the server-side methods as if they were sitting on the client-side. The server-side simply describes what classes and methods are available on the client-side. This allows for code to be organized in a fashion that is maintainable, while providing a clear path between client and server, something that is not always apparent when using URLs.
Intrinsic Call Batching
The provider immediately batches together calls which are received within a configurable time frame and sends them off in a single request. This assists in optimizing the application by reducing the amount of round trips that have to be made to the server machine. If a series of calls are received within the specified timeout period, the calls will be concatenated together and sent off to the server as a single request.
Server-side Stacks
In order for Ext JS’s Direct protocol to work you must have a compatible Ext.Direct Server-side stack residing on your server. The server-side stacks use a ‘router’ to direct requests from the client to the appropriate server-side method. Because the API is completely platform-agnostic, you could completely swap out a Java based server solution and replace it with one that uses C# without changing your JavaScript at all. Ext is providing a complete remoting specification along with several reference implementations of different server-side stacks in PHP, .Net, Ruby and ColdFusion. Each of these are licensed under an MIT license, so that the community can expand upon what has already been done and integrate them into their favorite MVC framework such as Zend Framework or Struts.
An Example – The Ext Support App
Support subscribers have a new tool at their disposal to receive a response from the Ext Team. We have developed the new Ext-based application that will be used to streamline the process of managing user support queries . The Ext support application is built on top of Ext 3.0 and utilizes Ext.Direct extensively.
In order to see the benefit of Ext.Direct more clearly, let’s take a look at how we utilized it. Ext.Direct enables server-side developers to easily expose methods from the server-side to the client-side. In this example, we are exposing two methods of the TicketAction class – getTickets and getOpenTickets.

We can now call these methods as if they were local client-side methods without worrying about how the request is sent to the server-side and how the response is processed. We can also use these methods to populate an Ext.data.Store with the new DirectStore object.
var store = new Ext.data.DirectStore({ storeId:'open-tickets', directFn: TicketAction.getOpenTickets, //it's really that easy paramsAsHash: true, idProperty: 'tid', fields: [{ name: 'tid', type: 'int' }, 'title', 'display_name', { name: 'last_post_time', type: 'date', dateFormat: 'timestamp' }], sortInfo: { field: 'last_post_time', direction: 'DESC' } });
The TicketAction.getOpenTickets method can be called at any time, it is not required that it used solely in conjunction with a store.
I hope that the simple example above illustrates how Ext.Direct can help you better organize your client-server communication in your applications.
Ext.Direct Forum
We have added a new Ext.Direct forum under the the Ext JS 3.0 category. Several community members have already submitted server-side stacks for their favorite environments. We already have a list of several server-side stacks in a stickied forum thread. We encourage the community to contribute back server-side stacks for their favorite environments by implementing the Ext.Direct Remoting specification. There are five sever-side stacks currently available in our Ext.Direct pack with more implementations soon to come.










Looks sweet, another thing for us to take a look at!
What is the difference between using Ext.direct API and plain Ajax combined with MVC on the server side other then being able to automatically batch multiple requests?
In both cases you’ll have to duplicate your logic on the client and server side.
You are saying that with Ext.direct I’m not bound to s single server side solution but the truth is that instead of using the usual Ajax and polling I’ll get tied to Ext.
This is an excellent article evan.
Excelent article.
As pablo says, yes i understand this as getting tied to Ext. Making server code to work only with one frontend(ExtJS), doesn’t look too fancy for me. If i want to make another frontend, lets say in Delphi for windows to get the same data its used in the server i would have to make other normal ajax functions to get that working in the other frontend.
But if you are going to use only ExtJS for the front end i can see that its good to use this.
I will have to try it anyways, i am expecting to use it in a new application i will made sometime in the future (when client decides to make it).
Meanwhile its an interesting concept and this article explains some of the big confusion on using it.
Thanks Evan
Pablo, you’re not getting “tied” to ExtJS — you’re investing in them.
Hi, i am a newbie in extjs. I have a problem with tabPanel.How to use autoLoad url web page action in a existing panel. If suppose i had autoload url and this url contains login page and after filled require fields when i press submit button, the content should be display in existing panel.
Great article, thanks Evan!
Thank you so much!! awesome article!!
This is an innovative approach to solving a known inconvenience. The Ext Team continues to impress us. Keep up the great work!
I’ve been checking every day for this article! Thanks guys – this is golden!
What I find most attractive about Ext.Direct is the language neutral approach. There are many excellent server-side frameworks that merge the client and server with the stubbed approach. But it always felt like you were tying your application down. With Ext.Direct you gain the benefits without the specific language binding.
Sure, your server implementation will be language specific. But everything about the client generated code is not. I look forward to this exciting new approach.
Like any technical solution, this targets a particular set of problems that you might or might not have. Batch updates and a single place for the server-access code are big pluses. You’re free to stick to the previous approaches on the client, as well as layering your server-side code – with facades, for example -, if you are concerned about being tied to a client platform.
不错,很好,http://www.myext.cn
请问楼上的朋友,怎么才能联系到您,,我是ext中文站的frank。
关注
It’s look very very nice !!! – Congratulation!!!
But the server side stack seems doing the same thing as WebService does, but with a “webservice client” built with EXT exchanging json instead of soap…
What about JSON-RPC 2.0, do you think of supporting this?
http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal
That sounds really nice! I’m currently using DWR for the same purpose but if there’s a native Ext solution then I guess I should give it a try, maybe I can stop depending on a 3rd party library and make my Java projects lighter (1 jar less at least).
kabinde 1 numara kalite artı işcilik.
I am grateful to you for this great content.aöf
You can find it and all the information about it in this topic. I will be posting there and updating the first post about any changes. If you are not yer familiar with Ext
If you are not yer familiar with Ext.Direct, it is a package in Ext JS 3.0 that makes communication between your client and server extremely easy.
That sounds really nice!
You can read about it in this official blog post.
I can stop depending on a 3rd party library and make my Java projects lighter
In order to see the benefit of Ext.Direct more clearly, let’s take a look at how we utilized it.
The RemotingProvider empowers the developer by mirroring server side methods on the client-side and allowing them to call the server-side methods as if they were sitting on the client-side.
Just to remind before creating App
* How to organize code and where to place appropriate business logic.
* Parsing and formatting data on the server side.
* Keeping a maintainable structure.
* Parsing Ajax responses and retrieving error conditions.
* Doing data validation in multiple areas.
Excelent article.
As pablo says, yes i understand this as getting tied to Ext. Making server code to work only with one frontend
Keeping a maintainable structure is really important.
We’ve become accustomed to partaking in complicated design patterns to help separate logic from presentation – forcing the browser to play the role of a dumb terminal.
While the RIA movement has unshackled the web browser from that awful fate, accessing our server side logic remains mostly unchanged. Ext.Direct aims to solve this issue for developers creating Ext JS applications by providing a single communication point with the server-side
There are five sever-side stacks currently available in our Ext.Direct pack with more implementations soon to come.
The Remoting Provider empowers the developer by mirroring server side methods on the client-side and allowing them to call the server-side methods as if they were sitting on the client-side.
Hm… looks nice! I`ll give a try.
your ExtDirectDelphi is very excellent,Support and thank you!
Always impressed with the quality of your prods!
I’ll try it myself to see how great it is.
Hi, i am a newbie in extjs. I have a problem with tabPanel.
looks indeed cool.
Can’t we use it in Java Projects?
Good question – how about Java Projects?
That sounds really nice! I’m currently using DWR for the same purpose but if there’s a native Ext solution then I guess I should give it a try, maybe I can stop depending on a 3rd party library and make my Java projects lighter (1 jar less at least).
written to take advantage of more of the native functionality in sasassssss
Thanks to developers for this wonderful release!
Currently I’m using Ext.Ajax with JSON. I communicate to a PHP Backend using Zend Framwork (MVC approach).
I don’t see many differences.
Traditional call using AJAX with MVC
url: “/MyClass/myMethod/”
Ext.direct:
directFn: MyClass.myMethod
Even though Ext.direct provides some good features like batching, I think it is targeted for those not using MVC.
Thanks for this. Really good stuff.