After studying it and google its working I found its basically a file called api.jsca located at the root folder for each SDK Titanium version (which is the opensource version). After reading about it on its blog, I found that they actually promote developers to use it.
The file “api.jsca” consist of all the information Appcelerator uses to document their APIs, so the file is huge (over 36 MB of JSON data). Parsing this file in realtime consumes too much memory, so I googled if someone had the same issue, and found a github user called yomybaby that had an autocomplete (based on api.jsca) for the Atom.io editor. I found I could use that same structure and translated its functionality into Coldfusion (Creador OPEN is made in Coldfusion, so the performance is better in its native language). This leaves me with a file ti-completions.json (yomybaby had it as js module file, but I preferred it as JSON for Coldfusion) of about 1 MB instead of 36 MB.
Put simply I now had a file which had all the properties of the current SDK, their possible values, the xml tags (which are the views) and their corresponding proxy objects (because if you use a view as a script we must use its full proxy name with a ‘create’ prefix).
A DSL controls everything about its way of handling things: this includes the generation of autocomplete features for using it inside Concepto DSL, the auto-creation of an updated PDF with all descriptions, attributes, events and usage, the way the properties and live update of content handles the realtime modification of code (live mode), and the way it interacts with all the chain of commands needed to create an application from it (for example: creating google-api keys, launching the command line scripts that Titanium requires, creating and emulator, checking the GUIDs for each IOS emulator or connected device, etc). For this, each command that has a DSL contains a structure with the data to include in the documentation and the autocomplete export commands, and to define how it is detected as the ‘preferred’ command to be used by the compiler.
Concepto Spanish TI DSL contains currently over 100 commands, each with its own documentation. I thought, well if I translate all this 100 commands by hand i will eventually finish in about a month, but using this ti-completions.json file, I thought I could adapt it to serve as input for my Concepto parser.
This took me about 4 days, but the result is now that I have 380 pages of documentation ready in English, in the same classic format for Concepto, auto-updated for each SDK and taking into account all deprecated methods, attributes and events for each case. I also have now the autocomplete commands ready for all views, and the ability to create new commands extracting the attributes supported for a referencing proxy object.
As you can see in the above example code, I made a method called ‘ac_ti’, which references all the objects of Titanium that matches the given ‘tag’ (in this case, views are all tags) or ‘obj’, where * means i want all of them. Each autocomplete item is a duplicate command based on the definition for the current command, where the ‘extra’ field adds a specific child field to each copy (in this case so that all view command require the icon ‘idea’ to be identified). The ‘pro_value_mapping’ means I wish to add aliases for the values of some of the attributes of each included command. For example, in this case I wish to add the value ‘*’ and ‘-‘ to both ‘width’ and ‘height’ properties of each object, in which case if they are used, they must be written as ‘Ti.UI.FILL’ and ‘Ti.UI.SIZE’. This is basically to maintain the way some nodes already work with Concepto in Spanish. This instructions, tell the parser of the compiler that this rules are also to be considered when generating the PDF manual of this DSL and the autocomplete commands for Concepto. This method also adds the extra value mappings to the function command for processing the nodes, and the corresponding needed aliases for setting and getting the realtime code updates from Concepto Live.
This english DSL is still not ready for creating full applications, because I need now to add all the scripting commands which are not in the doc apis. I mean with this the ‘events’ associated with the views, and the ‘conditionals’ (if, elseif, else, etc), but it’s a good start.