8 May 2009 11:32 AM #1
Ext.Direct - Server-side Stacks
Ext.Direct - Server-side Stacks
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: http://extjs.com/forum/showthread.php?t=70619
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
Perl Stack - Maintained by (scottpenrose) Scott Pennrose
CatalystX::ExtJS::Direct - Enable Ext.Direct in Catalyst controllers
RPC::ExtDirect - Full-featured and well documented Ext.Direct stack
extdirect.django 0.2 - Maintained by (sancho_0) Santiago Videla
Django Stack - Maintained by (Svedrin)
Maintained by stju (Juris Vecvanags)
Last edited by Stju; 11 Apr 2013 at 9:42 AM. Reason: Add node.jsAaron Conran
Sencha Architect Development Team
13 May 2009 12:30 AM #2
What about perl stack? It is mentioned in specification, but not present here.
13 May 2009 5:56 AM #3
+1 for a Perl stack
13 May 2009 2:44 PM #4
13 May 2009 4:25 PM #5
Ext.direct for C ?
Ext.direct 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 ext.direct, 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.
13 May 2009 5:42 PM #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?
14 May 2009 7:43 AM #7
- Join Date
- Apr 2007
- Sydney, Australia
- Vote Rating
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.Evan Trimboli
Twitter - @evantrimboli
Don't be afraid of the source code!
14 May 2009 7:53 AM #8
14 May 2009 10:04 AM #9
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.
14 May 2009 10:52 AM #10
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 ext.direct 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.