×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
From: Niels Liisberg
The trace with both the screen and the JSON format is only for
debugging purposes.
Okay. I took another look at your code and saw that the "C" module was outputting a trace in JSON format for debug purposes, while the RPG module was outputing HTML and ExtJS code.
It's more clear to me how your design offers a lot of flexibility for RPG programmers.
One one side, your "C" service program shields RPG programmers from the complexity of the 5250 stream and exposes a simplified set of procedures and data structures. I REALLY like that! It would be great to see that interface extended to support *DSPF windows, and other *DSPF capabilities.
Then on the other side, the RPG programmer could generate an HTML stream, or a JSON stream, or any other type of stream supported by the intended client. That client might be using ExtJS or some other rich interface, or might even be something else, other than a browser technology.
In "the real word" the JSON formatting has to occur in the "front
end" application. I haven’t have time to make that right, but that will
actually change the UI paradigm.
Yes. I understand that. Is Rob Dixon is paying attention to this thread? If his database utility already offers a 5250 interface, an ExtJS client or something similar could be a good alternative to the CGIDEV2/HTML approach that he's working on.
I'd also be tempted to work on some sort of AJAX client, talking to an RPG server, using your virtual terminal interface.
This has a lot of potential to bridge the gap between new Web interfaces, and existing 5250 interfaces, or even new 5250 applications that folks may have in mind, by deploying them all together under a Web portal.
Nathan.
midrange.com
