Overview

The Flynet Viewer development toolset has an extensive capability to capture the data-flows and relationships in an existing screen-based legacy application. Starting with the Recorder, screen workflows are captured in full detail to recording files. The Viewer Studio then imports screen images from recordings; identification rules are set and the Mapper View maps and names data fields.

The Viewer Studio Framework may then be used to generate individual modules on through to entire applications. The framework combines comprehensive access to all the screen definition elements as well as the information captured any and all of the recording files.

Benefits of Code Generation

New applications can benefit significantly from secure, robust integration of the data and functionality contained in existing screen-based applications. The challenges in the past for developers have included difficulty in understanding and documenting the host applications, then implementing effective integration code.

The data flowing in and out of screen-based applications must fit on an individual screen, with each screen only holding a limited amount of data fields. The ability to move from one screen to another requires the knowledge of the correct key sequence to initiate the move, also called navigation. Building the access classes, methods and properties that adhere to the existing screens is tedious, with many opportunities for errors and omissions.

The Flynet Viewer V4 tools introduce new capabilities that enable developers to overcome these challenges quickly and with minimal effort. Screen applications can provide a rich set of data entry, update and access functionality that the Flynet Viewer toolset is designed to record and map. This recording and mapping of the the data flows is stored in both the recordings as well as the screen definition files that are edited by developers using the Flynet Viewer Studio.

To minimize the need to hand-code the "glue" classes that interact with the strict screen access mechanisms, the code generation framework of Flynet Viewer Studio leverages the captured information in the recordings as well as the field maps in the definition files. Using established designs and coding patterns based on years of experience in the implementation of screen application front-ends, the authors of the code generation templates can build on the "glue" to create clean, easily interfaced classes.

The output of the resulting code-generation templates and wizards provide both automation of the access as well as a solid building-block on which a fully customized, new user interface or Service Oriented Architecture layer can be based.

How it Works

Templates for common applications, such as Web Services and ASP.NET application front-ends are provided by Flynet and our business partners. While described as "templates" they are implemented in a variety Flynet Studio Plug-In modules, with the two primary plug-in classes being the "simple template" and the "template wizard". In addition to those plug-ins provided by Flynet and our partners, customers and service providers may also author their own plug-ins, using provided assemblies and documentation.

Key concepts of the code generation architecture include:

CodeSmith Templates

CodeSmith templates are used to "drive" the actual generation of modules. The number and use of the individual template files depends on the generation task being performed. Sitting in-between the CodeSmith template files and the Flynet Viewer Studio are the individual wrapper assemblies that "plug-in" to the Studio to bridge between the screen definitions and the code-generation templates.

Wrapper Assembly

The wrapper assembly acts as a bridge between the Studio user interface one or more CodeSmith templates used for a particular code generation task. The assembly is either a "Wizard" wrapper or a simple "Template" wrapper. This assembly may be authored in any supported .NET language. The wrapper assembly includes a number of public properties with special attributes assigned to those properties.

Extended Properties

Depending on the attribute settings of each wrapper assembly's public properties, when loading the assembly, the Flynet Viewer Studio will "add-in" the specified property to the collection of meta-data managed for a set of screens representing a legacy application. For example, a screen field map may have a property "iSeries SubFile" so that the code generation wrapper can treat the map differently than if it were for a plain screen

User Interface

Based on the installed wrapper assemblies, the Flynet Studio user is provided a list of templates (as a tab in the workspace view) as well as a menu tree of plug-in Wizards under a Tools menu. The choice of Wizard plug-in or simple Template (with accompanying property sheet) is determined by the author of the template wrapper assembly. Note also that any defined extended properties will affect the user interface while editing definitions, by adding additional properties to each object type, such as a field, a field map or screen definition.

Summary

Leveraging CodeSmith, a popular and proven, highly functional application templating technology, the Code Generation Framework of Flynet Viewer Studio minimizes the coding of detailed, mundane screen interfacing code. Building on this, whole Web Service components, ready for further enhancement can be generated, with complete ASP.NET web applications right around the corner.

< Page 1 Page 3 >