Renaissance is a framework of RPG ILE programs, service programs, JavaScript, and HTML designed to enable developers to quickly and easily build high-quality browser-based intranet applications for IBM i.
Applications built using the Renaissance Framework run on the IBM i Apache HTTP server, utilizing the CGIDEV2 service procedures in order to deliver web pages to a browser. Renaissance uses AJAX technology to provide the end user with smooth page transition and seamless server/browser interaction.
Renaissance is developed by CoralTree Systems Ltd, and it’s freely available under the Open Source MPL License Version 1.1.
Some of the facilities that Renaissance Framework provides include:
- WYSIWYG screen designer with full drag and drop capability (available early 2011)
- Multiple environment support from a single server instance (Development, Module Testing, Acceptance Testing and, of course, Production)
- Proper library list support for all resources
- Web services as a client and as a server
- jQuery integration for the UI
- Integration with change management tools such as SEE/Change
- Full internationalization capability
- Full session management for maintaining state across multiple page requests
- User security with role-based authority to each function
- Renaissance services (CRON for the IBM i)
- The ability to define your own data tables and allow the end user to maintain data through functionally rich web pages without writing a single line of code
- CSS based themes using jQuery UI
- Multi-machine support (run your Apache server in the DMZ and your CGI applications behind the firewall)
All programs called via your web browser run on the IBM i and are written in ILE RPG IV. In this way dynamic web pages are built and served to the browser by the Apache HTTP server hosted on the IBM i, which is included with the IBM i OS. No additional hardware or software is required.
Renaissance is split into two main libraries: RNS for the framework application and RUI for the software responsible for the UI. An additional library called RGD will soon be available to co-exist with RNS and RUI. This handles the WYSIWYG screen designer and is described in more detail later.
The Renaissance Back Story
The driving force behind the creation of Renaissance was application modernization. The biggest application that CoralTree develops and supports is a green screen Subscriber Management application that can have many call center agents using the system at the same time. The application is functionally very rich, but it requires a lot of training before any new user can become productive. Call centers have a higher than average turnover of staff, so it was essential to find a way to reduce the time (and therefore cost) of getting new people up to speed.
Most people these days are familiar with browsers and GUIs, but they are far less familiar with a green screen. A browser-based front end to the system therefore appeared to be the best bet. HTML, CSS, and JavaScript provide a way of creating a very functionally rich GUI these days, and the fact that it is browser based removes the need to install something on every desktop in the organization.
At the beginning of 2005, we started looking for options. We looked at various things, including .NET, but eventually we found a nice simple option called CGIDEV2—a service program that simplifies the interaction between Apache, the existing APIs, and RPG (or COBOL). This gave us the basis for generating content in a language we knew well (RPG) and delivering to a browser on a platform we also knew well (IBM i). However, CGIDEV2 does not give you all the things you need to develop a proper, robust framework on which to build your applications. It was our view that the following things must also be present:
- A way to maintain state using session management
- Built-in internationalization support
- A way to separate the tier responsible for building the content from the business logic (MVC if you like)
- Built-in function and field level security
- Standard service procedure based ways of building HTML elements to ensure consistency (regardless of developer skills)
- A way to support development environments using library lists, including integration with change management systems.
- API integration with legacy systems
- Web service support (client and server)
- Powerful configuration options without the need for building maintenance files and programs
With these things in mind, we started to build a framework that supported these requirements to sit on top of CGIDEV2. We had version 1.0 ready by February 2007, by which time we had already decided to make the framework freely available to everyone under MPL 1.1. Since then the framework has grown steadily in terms of stability, functionality, and, most importantly, has helped us solve the problem it was originally intended for.
Application Look and Feel
All applications written using Renaissance will have a similar look and feel, although the themes are customizable as well as the logos etc employed. Figure1 shows the typical layout of the screen, and information, logos, and control buttons appear across the top.
The menu and other widgets appear in the side bar on the right side (which can be collapsed). The widgets in the sidebar can be re-sequenced using drag and drop and collapsed or expanded. The state and position of each widget is remembered for the next time you log in.
The rest of the page represents the viewport where the majority of CGI programmers will place their content. This screen in particular shows an example of the types of things that can be done with the jqGrid user interface.
The layout is all driven by CSS so it is possible to customize and tweak the layout if required, but most just take the default.
The Topology of an Application Based on Renaissance
A typical RNS application can be divided into the following tiers:
- The browser
- Apache on the IBM i
- The CGI program
- The back-end server(s)
The CGI program is responsible for creating the UI using the various procedures and service programs provided by the framework. It does not normally know anything about the database environment or business logic, although it can if that is your preference. It communicates with back-end servers via data queues.
The back-end servers have full access to the database and are able to perform business logic functionality (validation, CRUD, etc). They may also optionally communicate with legacy applications via APIs, or they may communicate with third party systems using web services (Renaissance has inbuilt service procedures to enable it to both consume and serve web services).
It is also possible to insert an extra tier when you want to run the Apache server in a DMZ but keep the application tiers on a separate machine behind a firewall. This is achieved via a simple configuration change that tells RNS to use its own request dispatcher functionality over DDM data queues. This works in a similar way to an Apache reverse-proxy installation but without the need for two Apache server instances.
The Presentation Repository
The Presentation Repository (PR) is the hub of Renaissance. All files, fields, constants, and buttons are defined and stored here. They may also be translated to any language. When a component from the PR is included in a screen, its appearance and behavior is dictated by the properties within the PR. This means that when a programmer wants to output a field on a screen, they do not need to consider how it is displayed, just that they want to display it. The fact that it is rendered as a textbox or a dropdown box or a checkbox or a radio button is not something that has to be considered. Of course, programmers can override the PR in their program if they wish. Figure 2 and 3 show examples of the PR information for a file called XUSER and properties of one of those fields—XUSACTIVE.
Menus, Configuration, and Authority Control
All configuration of Renaissance is achieved via the Cross Application/Configuration menu. Functions (CGI programs) can be defined here, which may be allocated to roles. Users may have one or more roles associated with their user id. The menu items they see when they log on are therefore driven by their role(s) and the functions associated with them.
There are many configuration files and authority control files provided with the framework to dictate the behavior of various parts of the system. As with functions, configuration files can be allocate to one or more modules and functional areas. Administrators of Renaissance installations are free to create as many extra application specific configuration files and authority control files as they need to create additional control over the behavior of their applications.
Configuration files and authority control files are not individual physical files in the traditional sense. They are fully defined within Renaissance. You can just create a new configuration file, define the attributes (fields) in the PR and you can then add/delete/copy/view data within your file without having to write any code or compile anything. An additional feature allows you to also import any legacy code files that you may already have. You just tell Renaissance the name of the file you wish to include and you will automatically get a fully working maintenance facility within Renaissance for your file. You may also export configuration data in XML format to enable you to import it into another Renaissance system.
Figure 4 shows an example of one of the configuration files in Renaissance. Here we can define the locales that are available to associate with users. LOCALES are found within a configuration group called PARAMETERS. The “Structure” button allows us to define the various properties of the configuration file, like general information and description, attributes and relationships with other configuration files.
Attributes (fields) just like everything else, are defined within the Presentation Repository, as shown in Figure 5.
Once all this configuration information is set up, then you can easily retrieve it within your programs to enable you to influence behavior using service program procedures. For example, if you want to retrieve the description, date format and date separator for the ENU locale you can just do this:
CFG_Chain( ’PARAMETERS/LOCALES’ :’ENU’);
if CFG_Found();
description= CFG_GetField( ’LOCALE’);
datefmt = CFG_GetField( ’DATEFMT’);
datefmt = CFG_GetField( ’DATESEP’);
endif;
How Does the WYSIWYG Screen Designer Work?
RGD works in exactly the same environment as RNS, so there are no additional tools required. When RGD is present on your system, a button is provided on your normal RNS page to enable you to switch to RGD mode.
Figure 6 shows the default initial layout. As you can see it is pretty much the same as the normal RNS screen, which is essential for you to able to truly get a WYSIWYG development experience.
The main differences are that the right hand side bar now (initially) contains three widgets:
- A list of pre-prepared templates
- A list of functions that you already have in your development environment
- Theme chooser
The viewport is now basically the palette onto which you can now drag and drop a template (either to enhance it or convert it to a function) or a function that you wish to modify. Initially the palette contains text to give you some information about where to start.
So, for example, if we drag and drop the XJQGRID template from the template widget and drop it onto the palette (view port) then RGD will render the template on the screen as shown in Figure 7.
Now the side bar content changes again since we are now designing/changing the screen itself. We now have a new widget containing the list of available components that we can drag and drop onto the palette. We also have the Presentation Repository widget from which we can drag and drop fields and buttons that we have defined there. The properties widget changes dynamically every time we click on a component in the palette, enabling us to modify the bespoke properties of the component in focus.
The final widget is the main controller. From here we can instruct RGD to save our changes, or use “Save As” to convert a template to a real function or to copy one function to another. For functions, we can generate the RPG code required to build the screen we have designed. We can also view the code and preview the output. Preview effectively generates the code, compiles the program and then runs it, showing you the results in a preview mode on the screen.
The code generator only generates the code required to produce the screen you have designed. You can then modify the program to include bespoke functionality and its interaction with the back-end servers (if any).
The output from RGD is a special XML document called RML. This is stored in the IFS for templates, and in a compile time array in functions (CGI programs). This means that you can revisit the screen design and regenerate the code as many times as you like. Only the screen design part of your program is regenerated—all your bespoke changes to other areas of the program remain intact.
For the sake of simplicity, let’s look at the “fieldcontainer” at the top of the palette. The heading says “Caption” but we can change this to any translatable piece of text that we have stored in the Presentation Repository just by editing the properties of the “fieldcontainer”. We can also drag and drop as many fields as we want from the Presentation Repository (PR) widget into the “fieldcontainer”. In this example we have dropped in two fields (User id and User name). The look and feel of each field is defined in the PR, so it may render as an ordinary field, or a checkbox or radio buttons or dropdown box, etc.
In Figure 8, we have clicked on the “fieldcontainer” at the top of the design palette. Notice how the properties editor now shows the properties for the field container itself. The “columns” property says how many columns of fields we want to have. If we change it to from 3 to 1 and press “Apply”, the fields in the container now appear in a single column rather than side by side, as shown in Figure 9.
If we are not happy with the sequence of the fields in the container, we can click the “Fields” button, which brings up brings up the field sequence editor, in which we can drag and drop the fields around until we are happy with the sequence—and then click “Apply.”
The changes are immediately reflected on the palette. The same technique works for all components. You click on the component, modify the properties, and apply them.
At any time you can close the current design session with or without saving your changes. This can be useful when writing specifications, where you want to want to design a screen and include it in a Microsoft Word document or PDF.
You can, of course, optionally save your design as a template so that the programmer can pick it up and convert to a function when the development work starts. This can save a lot of time because the screen design process only needs to be done once.
RGD also has a facility to view the RML of a model at any point in time. It can then be copied and pasted into a document or email, and later imported into RGD using the import facility. This means that anyone can create and save a model and email it to somebody, who can then import it into their own system. This provides a useful way of sharing templates and also a very useful diagnostic tool.
Kevin Turner has over 20 years in the IT industry, designing, developing and consulting on enterprise-level applications in a variety of industries. For the first 15 years of his career Kevin worked solely on an IBM System i platform in life insurance, publishing, banking, telecommunications, and subscriber management. More recently Kevin has extended into development for the web and mobile devices using the Microsoft .NET Framework and Renaissance Framework. Kevin began his IT career at Skandia Life (UK) in 1984 and has since taken major design and development roles in the UK, Singapore, and Australia for Chase Manhattan Bank, Pacific Associates, and John Wiley and Sons. Before jointly founding CoralTree in Feb 2004, Kevin worked for 12 years as a senior development manager for Convergys EMEA.
More Information
You can get more information by visiting renaissanceframework.com or by emailing kevin.turner@coraltree.co.uk. Plus, check out these resources online: