SystemObjects SmartPad4i Mobilizes RDi
April 3, 2017 Dan Burger
As more companies find their way into the RDi development environment, more ISVs realize plug-ins to RDi are in demand. SystemObjects just joined the list by offering an RDi plug-in to its Web and mobile application development tool known as SmartPad4i. For situations where Web development skills are still evolving, SystemObjects is offering a route that bypasses the Java and HTML learning curve. And there are always RPG and COBOL programmers who don’t mind that detour.
SmartPad4i is not new. But the plug-in to RDi and the built-in capability to create HTML files are interesting enhancements. IBM i developers with HTML skills don’t grow on trees, you know.
“I think SystemObjects is aiming at a very real need,” says Edmund Reinhardt, architect for RDi application development at IBM. “A lot of IBM i programmers do not have Java or HTML skills. So, having an ISV provide tooling that will get them to Web and mobile applications without learning that full stack is something they would really like. I have heard more than one large enterprise customer expressing a desire to get to the Web and mobile and lamenting the learning curve and wishing for a simpler path.”
The HTML Builder module in SmartPad4i puts applications running on Web browsers, tablets, and smartphones within reach of a lot more shops and it may give some of those shops a reason to use RDi for their new development efforts. It’s not necessary to use SmartPad4i in an RDi environment. Before this release, it was a standalone product. However, a combination of RDi and SmartPad4i has its benefits in terms of productivity and scope.
Before SystemObjects created its module for generating HTML, users had to learn to make it on their own, with files created with an HTML composer such as Dreamweaver or other proprietary and open source editors, or even on Notepad. This was a problem for early adopters of SmartPad4i.
“Each time I made a product presentation in front of IBM i developers,” says SystemObjects president Serge Charbit, “I started by explaining that HTML replaces DDS and you need to create your HTML file as the presentation layer of your application. I soon found out that almost 90 percent of the developers I talked with didn’t know how to create an HTML page.”
HTML business applications consist of two independent parts, as Charbit explains it. One element is the interactive form that includes features that help perform business-critical tasks and that increase productivity. The second element is the graphical presentation that is not interactive. It deals with colors, fonts, and corporate logos.
Developers take care interactive, business tasks. The graphical presentation should be handled by Web designers. It’s not linked to RPG or COBOL programs. That’s not to say that programmers can’t be Web designers. It’s just a suggestion that design is better left to someone with professional skills in that area.
“SmartPad4i-generated programs know only the ‘name’ of the object and doesn’t have information about its place on the HTML page,” Charbit says. “HTML Builder creates ‘blank’ HTML pages. They don’t contain any graphical design elements. They are source HTML5 files that are used to fully develop your new applications. Colors, type sizes and fonts will be added later by the Web designer. For the developers, there is only one line to add on the HTML file, a link to the CSS (cascading style sheet) file describing the presentation.
“HTML Builder will never replace a tool like Dreamweaver (or RDi which includes an HTML composer) and this module is only here for developers without any HTML knowledge and without any tools. HTML Builder generates HTML5 source files. You can use any tool to enhance these files.”
In addition to the HTML Builder module, SmartPad4i also a designer module and a generator module.
Source code of each RPG or COBOL program is generated by the designer module, which also manages the communication between the programs and the Web browser and/or mobile devices replacing DDS with HTML. It also provides the capability to access features on the mobile device such as the address book, camera, and GPS.
The RPG code for the database access and the application display functions is handled by the generator module. It also creates the logic required to display database records as well as allowing users to add, change or delete records. Users are also able to search records from a list, which has auto-complete capability–suggesting matches based on each character entered by the user.
Charbit describes SmartPad4i as “the missing piece of a fully integrated, end-to-end Rational Development for i environment.”
Productivity continues to be a big issue in the development debates that have the traditional green-screen developers resisting the move to RDi because, they believe, their productivity will decrease after switching from the environment they have known for so long. The RDi advocates say productivity loses would only be temporary and eventually the gains would out-pace even the most skillful SEU developers because of all the features in RDi – and the tools that plug into RDi – that are unavailable in the green-screen development environment.
“Modernizing the development environment is not a story that demands 100 percent use of RDi,” says Charles Guarino, an RDi subject matter expert who speaks at technical conferences worldwide. “Developers can still use SEU for things that can be done quickly and easily with SEU. I’m going to use a traditional hammer (SEU) to hammer a few nails, but I’m going to use a power hammer (RDi) if I’ll be hammering nails all day long.”
There’s a misconception that also plays a role in the SEU vs RDi debates, Guarino says. “People think RDi is simply another editor replacing SEU. RDi is an entire development environment. It’s not just a tool,” he says.
“Other vendors have made a good business in this very same niche,” Reinhardt says, “because green screen user interfaces have become such a road block to application adoption and popularity. Of course, there are always trade-offs, in that you will be dependent on that ISV for customizing the look and feel of the resulting application as well as obvious limitations on the flexibility of what that application can do. I imagine that there will customers who would be willing to make that tradeoff as long as they can depend on the vendor being there for them for the long run. IBM RDi is happy to partner with anyone who is able to meet the needs of our IBM i developers and extend the capabilities of RDi with IBM i-specific tooling. RDi is built on the Eclipse platform that was designed from the ground up to be extended and we welcome all vendors that take advantage of this.”