My $ 0.02
I too agree that HATS, screen scrapers and WebFacing are going to impose
limits you and your users will not accept. And I salute everyone
rethinking RPG program design for a better UI than DDS. Our shop is also
going through the questions of which Web Interface Framework to embrace,
and asking Java vs. PHP for web development. In my efforts to get ready
for a new UI framework, I am tackling program flow within RPG programs
by splitting our screen programs in an MVC style called Presenter First
http://en.wikipedia.org/wiki/Presenter_First
For those that are interested, here is my method to refactor programs as
they come in for maintenance. I only have a couple of these under
development, but feel the effort is going well. Their DDS screens still
exist and still function in the meanwhile, and even if totally
supplanted in the future with a different UI, they still may continue
to exist as test artifacts.
To start a program revamp, any reusable or potentially reusable function
is extracted. These functions tend mostly to be about generating
validation messages, with some retrievals of keys, and sometimes updates
to files. The Business Logic that can be extracted is placed into small
self-contained programs or modules (take your pick of RPG style) with
Testability built in. These tests that can be run by pgmrs, users or
automation software to validate these small, single responsibility
programs.
Then for the matter at hand, tackling the older UI, I begin with a
program to just get the screen(s) into data structures, using a
Presenter First pattern This facing program should only handle screen
events, like search to load screen fields, and just places Function Key
navigation requests like "Show Next Record" into an INDARA. All
resulting screen input and output data seen in the facing program goes
into data structures. Handling of function key events and field
highlighting indicators are deferred to another program which will
respond to actions stored in the INDARA.
Next, a Responder program accepts the handoff of the INDARA and the data
structures of all screen fields. The Data Structures created are simple
matters created using EXTNAME(Display:Format:*ALL), and structures for
saved-screen-fields are also created and passed between programs.
This program then "responds" to the requests with editing and file
positioning for the navigation requests. Lastly, if there are file
updates to occur, a third program does the update, again using the data
structures. This separates the file processing to it's own function,
which in theory, could be tested using automation, too..
Regardless of which Web Interface Framework is embraced, but by
designing in this style, our revamped RPG programs should be ready for
any interface (DDS or Web or Desktop RUI or iPhone and SQL UDTF SOA) by
only replacing the disposable front end Presenter program. And I expect
that all our older programs can be modified to be responders of
Structure.EXFMT.Format.Fieldname without too much heartache.
Now if IBM were to generate XML tags from DDS using the ALIAS keyword or
other Web-facing compilation magic, then we might rethink our handling
of these RPG antiques, but until then, I think the process above is the
way to proceed.
. . . my approach would be to let DDS screens go by the wayside, and
use relatively little existing RPG code
in the final product. I'd generate new applications based on new Web
2.0 UI templates and RPG models,
but may cut and paste data validation and business rules from existing
source, where applicable. . .
. . . recast it as a sub-procedure that can be called from either
green screen, ODBC / stored procedure,
PHP, CGIDEV2 or who knows what else.
midrange.com
