I know my inquiry is rather vague. Unfortunately, I haven't been given
clear direction. My best guess is they want something to allow
self-described "400 programmers" to write modern web front-ends with
backend RPG. No small task there.
Think about the scope and types of applications you want to deploy and the
types of users you want support because that can have a profound impact on
what tools and interfaces might work best for you.
In regard to types of applications:
- An e-commerce web site?
- A technical support portal?
- A dashboard that shows the results of queries and summaries using
charts and graphs?
Those types of applications tend to be fairly simple, don't require much if
any maintenance of end-user state. Even social networking sites are
relatively small in scope.
Contrast that with ERP-class systems that entail hundreds or thousands of
database tables. Interfaces that apply extensive data validation and
referential integrity checks. Interfaces that support and navigate within
hierarchical and sibling relationships between database tables. Interfaces
that apply access rights and authorizations across many types of users. In
that case you would do well to consider tools and interfaces that help you
deploy hundreds or thousands of database maintenance, transaction
processing, inquiry and reporting applications quickly. Perhaps interfaces
that support a community look and feel across many types of applications.
If your primary focus is on "400 programmers", you're probably tempted to
prioritize open-access interfaces that preserve the display-file write-read
paradigm. Those interfaces deploy a JavaScript applet that effectively
implements a display-file emulator in a browser. I urge caution about that
because that type of interface is terribly constraining in comparison to
the more common request-response cycle that truly robust user interfaces
require.
From my experience, it is best for "400 developers" to write applications
that implement a cycle where RPG programs receive requests from browsers
and return formatted responses (whether HTML, XML, or JSON). Allow the UI
to invoke any kind of request at any time and triggered by any client event
as opposed to programs that write records to a client then read prescribed
records from the client.
Applications that implement a request-response cycle can also be compared
and contrasted with the traditional CGI interface, which is similar to
stored procedure interfaces, in which "programs" are "called" by browsers.
One problem with traditional CGI is that the interfaces are stateless,
where your program may be running simultaneously in many HTTP CGI Jobs.
Stateless interfaces don't really support robust user interfaces, which are
more common in ERP-class systems. Consider implementing stateful
interfaces, which "400 programmers" can definitely relate to.
Food for thought.
Nathan.
midrange.com
