Page 1 of 10 123 ... LastLast
Results 1 to 10 of 100

Thread: Ext.Direct - Server-side Stacks

  1. #1
    Sencha User aconran's Avatar
    Join Date
    Mar 2007

    Default Ext.Direct - Server-side Stacks

    Link to spec:

    Symfony - Maintained by dancablam (Daniel Stevens)

    Ext.Direct PHP - Maintained by tommymaintz (Tommy Maintz)

    Simple Router - Maintained by Ext JS Team
    Within SDK - examples/direct/php/

    Ext.Direct PHP Backend - Maintained by ckr

    Ext.Direct for CodeIgniter - Maintained by goachka

    Ext.Direct for Kohana 3 - Maintained by Bodom78

    Easy Ext.Direct integration with PHP

    Ext.Direct CakePHP Stack - Maintained by Dumas

    Zend Framework 2 - Maintained by Rovak


    Rails - Maintained by christocracy (Chris Scott)

    Merb - Maintained by christocracy (Chris Scott)

    Ext.Direct .Net Server-side stack - Maintained by evant (Evan Trimboli)
    Ext.Direct for .Net 3.5 - Maintained by shibubh (Shibu Bhattarai)
    ExtDirect4DotNet - Maintained by crp_spaeth
    Ext.Direct for ASP.NET MVC - Maintained by elishnevsky
    ExtDirectHandler for .NET - Maintained by gianmarco

    ExtDirect stack based on Castle Framework (.NET) - Maintained by (aritchie)

    directjngine - Maintained by pagullo (Pedro Soliveres)

    extdirectspring - Maintained by ralscha

    extdirect4java - Maintained by piziwate (Steve Guillarmod)

    Ext.Direct Struts 2 plugin: extdirectj-s2-plugin - Mainted by stefanorg

    HQExtDirect - Mainted by cattus
    A new reflection based Java server-side stack implementation.
    Examples, additional information and packages you can find at the project's home page:
    Forum thread:

    DirectCFM - Maintained by aconran (Aaron Conran)

    ExtDirectCF: A Managed ColdFusion Server-side stack with security - Maintained by jimmifett

    Grails - Plugin: Ext Direct - Maintained by dferrand (Damien Ferrand)

    ExtDirect for Delphi - Maintained by r.federiconi

    4th Dimension (4D) v11
    4th Dimension (4D) v11 ExtRemoting component - Maintained by ahartlen

    RPC::ExtDirect - Reference Ext.Direct stack - maintained by (nohuhu) Alex Tokarev

    Perl Stack - Maintained by (scottpenrose) Scott Pennrose

    CatalystX::ExtJS::Direct - Enable Ext.Direct in Catalyst controllers

    extdirect.django 0.2 - Maintained by (sancho_0) Santiago Videla

    Django Stack - Maintained by (Svedrin)

    Pyramid - Maintained by (jenner)

    Maintained by stju (Juris Vecvanags)
    Last edited by Stju; 22 Oct 2015 at 2:54 PM. Reason: Updated spec location
    Aaron Conran

  2. #2


    What about perl stack? It is mentioned in specification, but not present here.

  3. #3
    Ext JS Premium Member
    Join Date
    May 2008
    Austria, Vienna


    +1 for a Perl stack

  4. #4


    php Kohana stack anyone?

  5. #5
    Sencha User
    Join Date
    Sep 2007
    Plano, Tx.

    Default for C ?

    Why not a C (and not C++) implementation? All of your supported stacks are slow, and resource hogs. None of your supported stacks are appropriate for embedded configurations. The only compiled stack is for the proprietary MSFT operating systems.

    Of course, I'm not complaining (well, only a little) ... glad to see, but there is a whole class of potential users for it are resource sensitive and/or have proprietary operating systems for the server. This eliminates .NET, JAVA, and your other choices, except for PHP, which isn't a good choice in general for embedded developers.

    Also, could you please publish full specs for the back-end? I.e, an operating system agnostic point of view or porting guide. Anybody who wishes to port to another language needs more than to just take apart the source code, especially since your source code makes calls to library functions that are built into the various back-end language stacks.

  6. #6


    +1 for perl, would begin coding against it today. Also, can there be/is there a JS-based stack for possible use with apps like freeswitch and couchDB?

    Thanks Ext!

  7. #7
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Sydney, Australia


    Ext is going to provide routers for the more popular server side languages. We're finalizing the specification now so that you can build one for your own platform.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  8. #8
    Ext JS Premium Member dancablam's Avatar
    Join Date
    Apr 2008
    Dallas, TX


    Quote Originally Posted by dlethe View Post
    Why not a C (and not C++) implementation? All of your supported stacks are slow, and resource hogs. None of your supported stacks are appropriate for embedded configurations. The only compiled stack is for the proprietary MSFT operating systems.
    The Ext team is leaving the development of most of these implementations up to the community. They can't feasibly create an Ext.Direct implementation for every imaginable platform. Also keep in mind that Ext.Direct is about 4 weeks old. More implementations are to come. If you're really in need of an implementation for your needs I recommend creating it yourself and publishing it to the community - the specs are reasonably simple.

    Quote Originally Posted by dlethe View Post
    Also, could you please publish full specs for the back-end?
    Here are the Ext.Direct specs:


  9. #9
    Sencha User
    Join Date
    Sep 2007
    Plano, Tx.


    The specs are relatatively incomplete, and unfortunately, recursive in nature. I.e, right at the beginning, the author writes, "... some features are not required for particular languages or may lack the features required to implement the functionality".

    I can certainly implement XML & JSON encoding/decoding, there are published specs. Wait, I can't implement it. The spec doesn't say basic things like which version(s) of XML do I need to be compliant with.

    The whole point of a server-side stack is to be language agostic from perspective of the client. Let's say I wrote a back end in imaginary language called "D"

    Does the D language require type conversion, or async method calls? The spec doen't give me a yes or no, so what is the answer? Explain in detail async method calls, Exactly what are all of the error codes . is there a limit to how long it can be? This opens up problem where clients need to have conditional logic depending on the back-end they use. Bad design. The client should only have to run a standard call to figure out best way to do something based by the response ... and all of this should be handled automatically by the framework. If server side doesn't support json, then extjs should (well, it would be nice) to convert to xml automatically and translate back to json so client browser code works.

    On rather simple file transfers, what do I do about file names that may not be compatible. What if somebody uploads filename ABC.TXT, Abc.TXT, and AbC.txt into same directory? Are these three different files or one file? OS / X will let you decide at installation time case sensitivity? What if the filename is to go into directory '?*.\\//', or the filename is "..\" or there are control characters in the file or directory name. Perfectly legitimate in UNIX, windows won't be happy. What if first character is a period? Do I expose it on a directory listing in UNIX?

    I know I am getting anal, but a specfication has to assume nothing, and certainly can't make assumptions about whether or not my programming language lacks certain features so I can't implement something, as the spec says.


  10. #10
    Sencha User
    Join Date
    Sep 2007
    Plano, Tx.


    I think best way to simply frame it, is that the spec is written so that the server-side language-specific defaults, libraries, and features are used as the default. From design perspective of server-side, that is good. You want to make sure that works with all of the default library code, for all obvious reasons.

    But for a new port, the spec doesn't provide enough information. The developer doesn't know what the default should be. PHP on Solaris and .NET on Windows XP have very different perspectives on everything from variable and expression parsing to file naming conventions. So what is a developer to do? I think you are going to run into some serious problems down the road unless you get very specific.

    The architecture guarantees that one can have a perfectly good ExtJS app behave differently depending on the server-side backend ... especially if there are bugs in client-side code. Are plug-in authors going to have to choose what back-end they support? That is like having plug-ins only work with certain browsers .. we hate that.

    A suggestion, develop a certification extjs suite that not only tests what should work, but what shouldn't work. Get the plug-in authors to work toghether on it. Each server-side engine must pass and fail each test within the certification suite exactly the same way. .i.e. test #27 tests rules that define acceptable whitespace. Test #28 examines bad whitespace, and if your server code is too tolerant, and the test passes, then you report that the server-side failed test #28 because it is just too tolerant.

    This test suite will be invaluable to developer, and will be most helpful when new versions of perl, php, coldfusion, etc, come out ... because we all know about how upgrades break things, or if certain server side engines break under certain operating systems. What if server engine works with one O/S, but not another? The cert suite can be part of the bundle that the installer runs to test things as part of the startup.

    Sorry for rant, I've written code for just about every O/S and CPU architecture you can imagine, from z80s to mainframes, and portability for software black-boxes is incredibly difficult to get right unless you leave nothing open to interpretation. (You must also rewrite the spec so the words SHOULD is replaced by MUST).

    Look at all the mess we have right now with browser compatibility and CSS. Nip it all in the bud ... now.

Page 1 of 10 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts