Ext.Direct - Server-side Stacks

[aconran]

PHP
Symfony - Maintained by dancablam (Daniel Stevens)
http://extjs.com/forum/showthread.php?t=67445
http://www.symfony-project.org/plugi...xtDirectPlugin

Ext.Direct PHP - Maintained by tommymaintz (Tommy Maintz)
http://extjs.com/forum/showthread.php?t=68186

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

Ext.Direct PHP Backend - Maintained by ckr
http://extjs.com/forum/showthread.php?t=68044

Ext.Direct for CodeIgniter - Maintained by goachka
http://extjs.com/forum/showthread.php?t=79211
Ruby
Rails - Maintained by christocracy (Chris Scott)
http://extjs.com/forum/showthread.php?t=67313
http://rubyforge.org/projects/rails-extjs/

Merb - Maintained by christocracy (Chris Scott)
http://extjs.com/forum/showthread.php?t=67313
http://rubyforge.org/projects/merb-extjs/

.NET
Ext.Direct .Net Server-side stack - Maintained by evant (Evan Trimboli)
http://extjs.com/forum/showthread.php?t=68161
Ext.Direct for .Net 3.5 - Maintained by shibubh (Shibu Bhattarai)
http://extjs.com/forum/showthread.php?t=67955
ExtDirect4DotNet - Maintained by crp_spaeth
http://extjs.com/forum/showthread.php?t=68619
http://code.google.com/p/extdirect4dotnet
Ext.Direct for ASP.NET MVC - Mainted by elishnevsky
http://extjs.com/forum/showthread.php?t=72245

Java
directjngine - Maintained by pagullo (Pedro Soliveres)
http://code.google.com/p/directjngine/
http://extjs.com/forum/showthread.php?t=73027

extdirect4java - Maintained by piziwate (Steve Guillarmod)
http://extjs.com/forum/showthread.php?t=67956
http://code.google.com/p/extdirect4java

Ext.Direct Struts 2 plugin: extdirectj-s2-plugin - Mainted by stefanorg
http://extjs.com/forum/showthread.php?t=69353
http://code.google.com/p/extdirectj-s2-plugin/

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:
http://bitbucket.org/cattus/hqextdirect/
Forum thread: http://extjs.com/forum/showthread.php?t=70619

ColdFusion
DirectCFM - Maintained by aconran (Aaron Conran)
http://extjs.com/forum/showthread.php?t=67983

ExtDirectCF: A Managed ColdFusion Server-side stack with security - Maintained by jimmifett
http://www.extjs.com/forum/showthread.php?t=70264

Groovy
Grails - Plugin: Ext Direct - Maintained by dferrand (Damien Ferrand)
http://grails.org/plugin/directext


Delphi
ExtDirect for Delphi - Maintained by r.federiconi
http://extjs.com/forum/showthread.php?t=71472
http://code.google.com/p/extdirectdelphi/

4th Dimension (4D) v11
4th Dimension (4D) v11 ExtRemoting component - Maintained by ahartlen
http://www.pelicaneng.ca/downloads.shtml


Perl
Perl Stack - Maintained by (scottpenrose) Scott Pennrose
http://extjs.com/forum/showthread.php?p=377723


Python
extdirect.django 0.2 - Maintained by (sancho_0) Santiago Videla
http://pypi.python.org/pypi/extdirect.django/

[SamuraiJack1]

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

[abraxxa]

+1 for a Perl stack

[woomboom]

php Kohana stack anyone?

[dlethe]

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.

[mike.slattery]

+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!

[evant]

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.

[dancablam]

Originally Posted by dlethe

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.

Originally Posted by dlethe

Also, could you please publish full specs for the back-end?

Here are the Ext.Direct specs: http://extjs.com/products/extjs/direct.php

Cheers,
Dan

[dlethe]

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.

David

[dlethe]

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.