What is TeraScript? - TeraScribe
TeraScribe is designed specifically to optimize developers' productivity in building and deploying scalable multi-tier web applications on Windows, Linux, and Mac OS X platforms.
The product is characterized by its highly visual approach that is particularly suited to the demands of complex business applications. It uses a graphical interface (actions) to visually separate the logic of the application into Business Logic (the control and flow of the application), Database Acquisition Logic (dealing with data retrieval from SQL databases), Presentation Logic (how the results are displayed to the browser), and External Data Acquisition Logic (dealing with interactions to back office systems such as email, XML, File I/O, COM, Javabeans etc). The result of visually separating the logic of the application is that the application developer can very quickly gain a fast understanding of the overall logic, structure and flow of the application. This in turn means that the development of an application can occur more rapidly and the maintenance cost of the code can be reduced.
TeraScript Application Files
TeraScript Application Files are created by TeraScribe. Each application file is comprised of a series of TeraScript actions and is capable of generating many different outcomes. In fact, the page the application file will ultimately render to a users screen is totally dependent on the path of actions which is executed in the application file. This means that each page is dynamically constructed based on the business logic contained in the file. To a developer this has the added advantage of centralizing common code where there are many variations to a common theme. Application files are saved in an XML format and can be easily transferred from one operating system to another. No recompiling of code is required.
TeraScript Actions are an icon-based representation of the application's logic. Actions exist to deal with all strands of required logic to build a complex application. Developers typically name each action as they use it in their application file which makes the application file 'self commenting'.
Business Logic Actions
Business Logic controls how the application flows. This is typically achieved with actions such as IF/THEN/ELSE action, FOR loops, WHILE loops, etc. The logical tests can be based on data from customer input, results returned from any number of different databases, objects or other external actions.
Database Acquisition Logic Actions
Database Acquisition Logic controls the interaction with available databases including select, update, insert and delete. TeraScript actions also exist for a developer to carry out ad hoc SQL statements or stored procedure calls with the direct DBMS action and to execute transactions that will rollback or commit.
Presentation Logic Actions
Presentation Logic controls how the results appear on the end users' browser, this is typically achieved with actions such as RESULTS or PRESENTATION which allow the developer to abstract out external presentation files.
External Data Acquisition Logic Actions
External Data Acquisition Logic controls the interaction with back office systems, this is typically achieved with actions such as MAIL, OBJECT, FILE, EXTERNAL. There is no limit to the number of different sources of data in a single application file, which is why this tool is well known as a powerful integration tool for applications which report on or merge data from many otherwise disparate systems.
TeraScript Class Files
TeraScript Class files allow developers to save TeraScript code-consisting of actions and tags-as objects for re-use in TeraScript application files or other TeraScript class files. TeraScript class files are available through the Object Workspace (other object types such as COM objects and JavaBeans are represented in a similar way). TeraScript class files can be used again and again by dragging and dropping them into new TeraScript application files; a developer only needs to write code once as a TeraScript-style object that can then be re-used in future projects. If the TeraScript class file worked once it will always work when reused, dramatically reducing debugging and development time.
Object Extensibility allows developers to visualize objects within the TeraScribe and integrate business objects and functionality that exist outside the TeraScript development environment. You can introspect objects to see their methods and parameters and, therefore, easily create applications that pass values to and retrieve values from external objects. Currently, TeraScribe supports COM objects (on the Windows platform) and JavaBeans (on Windows, Linux, and Mac OS X), as well as TeraScript's native object type, TeraScript Class Files on all platforms.
Snippets are available in the TeraScribe as a tool for developers to manager their favorite or commonly used pieces of code. Snippets can be dragged and dropped into any TeraScript application file.
TeraScribe incorporates two builders - the Search Builder and the New Record Builder. The code produced by the builders can be easily modified and expanded as required - effectively they can act as a total solution, or a really quick jump start to building complex applications. Developers have full control over the headers, footers and error handling in the application file generated.
The New Record Builder
The New Record Builder builds the actions required to add new records to a database. The developer simply drags columns from the table in the workspace into the builder window they wish to build an insert application for and the necessary forms, pages and insert statements are generated. The developer specifies any functionality which deals with required fields and available values (ie value lists, dates etc) and the necessary logical tests are incorporated into the generated TeraScript application file.
The Search Builder
The Search Builder generates the actions required to perform a search on a database, generate a record list and a record detail page and to optionally update and delete records. The developer uses the builder to specify which columns of a table (or joined tables if required) need to be searched. The developer then specifies which columns of a table need to be retrieved in the list of resulting matches, how the fields are to be ordered, how the records are to be sorted, which column should be used to link to further detail about a particular record etc, and how many matches are to be retrieved at each instance before a NEXT and PREVIOUS button need to be incorporated. Then, the developer specifies what fields need to be displayed on the detail of a record and if required which fields can be updated, and, whether or not this record can be deleted. The builder then generates the application file to handle all these requirements at the push of a button.
It is common for application developers to use these builders to very quickly get all of the 'grunt work' out of the way with no debugging required, then to modify the resulting code to meet specific and more complex application requirements.