We ve been going with Java and are all happy over here :)
Printable View
We ve been going with Java and are all happy over here :)
Unfortunately it happens on a regular basis - mostly from people that either don't work in the real world or don't work with other people. It's one of the reasons I"m pushing hard to dump Sencha from our department. I'm fed up with the attitude that they know better than everyone else - real or perceived, they allow it to go on.
If anyone cares, I've been trying to tackle this problem since Sencha doesn't seem to be interested. I've got both typed and untyped definition files for ExtJS 4.2 generated. You can find them at: https://github.com/brian428/ext-typescript-generator
I generated TypeScript interfaces for each concrete class to allow component config objects to be cast to an interface type when using Ext.create() or when implicitly creating components via xtypes, etc.
The typed version fully generates the "extends" superclass hierarchy, as well as the interface hierarchy for mixins (with classes marked as implementing the interfaces).
As a side note, you really don't notice how convoluted Sencha's APIs are until you have to reconcile it with a type system. There are crazy numbers of method overloads to handle methods that can accept variable types of parameters or return multiple types, places where a superclass defines something as a property or config item and a subclass defines a method with the same name, many places where the JSDuck docs are just wrong and specify incompatible param or return types in a subclass vs. a superclass, and so on.
If I have time I may try to push all this info into Sencha's support system, but writing it all up will be quite an undertaking.
I'll also probably try to blog about this to show examples of it working, since it took a bit of trial and error to get working. It's not totally straightforward because Sencha uses the Ext.create() factory method to create objects and TypeScript has no idea what that is. It wants you to use the new Something() syntax before it sees you're working with a class of a given type.
Anyway, it's there. Use at your own risk, don't expect instant answers if you find bugs or have problems, and all the other usual caveats. I have a day job too. ;)
Just a "heads up" that the latest edition of IDEA IntelliJ 12.1 now provides debugger support for Typescript (and Coffeescript) via Sourcemaps.
Sourcemaps are files that map source files and line numbers in the original input language code to line numbers in output language that is run by the debugger. This can be used to map minified JS code to the original unminified JS source code OR another even another input language like Typescript or Coffeescript. This then allows a JS debugger running on the output code (minified Javascript) to set break points on the original source code (Typescript or Coffeescript or unminified Javascript). GWT also support this HTML5 feature now.
This is actually an old idea (See JSR-045). Java JVM debuggers like that in Eclipse have supported this for many years. They allow you to set break points on languages like Groovy that are translated into Java and then into JVM byte code.
I've fine-tuned my generator and have gotten the definition for Ext JS 4.2 merged into Boris Yankov's DefinitelyTyped repository. It contains a master list of 160+ library definitions and is automatically made available via NuGet.
https://github.com/borisyankov/DefinitelyTyped
Since I made my JSDuck to TypeScript generator generic, I've now added definitions for Ext JS 4.2.1 and Touch 2.2.1 to the DefinitelyTyped repository.
Thanks Brian ... Your contribution is very much appreciated.
For anyone who hasn't looked into it yet or thinks TypeScript wouldn't be useful, this presentation covers the latest release and provides a great overview of what it does and how it works. The tooling and IDE benefits are extremely impressive.
http://channel9.msdn.com/Events/Build/2013/3-314