|
> Programming business green screen apps doesn't mean you did CGI programming. >Write some RPG CGI apps, let folks critique your code (as I do on the JAva >list), then I'll accept your opinion of it. That's not too much to ask. -------- This is a very interesting statement. You seem to think that CGI programming is some different, higher order of programming than other RPG programming. That those of us who have coded in RPG for a couple of decades aren't qualified to have an opinion on this "new" technology of CGI-RPG. I'd like to review that. Standard green screen application: initialize, read data, write to a screen preformatted via DDS. Wait. Read input from screen. Process that input, updating the database as necessary. Repeat. CGI application: Call APIs to recover my state. Call APIs reading input from browser. Process that input, updating the database as necessary. Read data, formatting an HTML panel for the user. Output the HTML using some APIs. Let's see here. The "process that input, updating the database as necessary" part is pretty much the same for CGI as for traditional programs. Business logic is business logic, although you have some additional complexity to handle stateless transactions, such as cookies. But other than that, it's pretty much read database, do calcs, write database. No magical skills required that me and the other RPG dinosaurs don't have. And the "recover my state" business? RPG II programmers were doing that in the 70's - it's called NEP-MRT processing on a System/3. No, the bulk of the difference is in the I/O portion. And what's different? Well, in CGI you have to format your entire data stream, appending HTML tags in the appropriate places. So the bulk of the difference between traditional programming and RPG-CGI is the formatting of the output stream and the use of APIs to communicate with the UI. To me, that means that the primary difference between traditional RPG and CGI-RPG centers around using RPG for things it's not particularly good at: string formatting and stream I/O. Now, I admit you are probably much better at writing stream I/O in RPG than I am, Brad. And I can guarantee this, you'll likely REMAIN better at it, because to me it makes no sense to me to use the language that way. And I have plenty of experience doing CGI programming using servlets. There is absolutely zero conceptual difference between CGI programming in RPG and CGI programming in servlets, except perhaps that servlets are better at preserving state than RPG-CGI. That's why the JavaServer Page API was invented: the folks who were using CGI realized there needed to be a better way. I won't write CGI-RPG, Brad. It's a strategically unsound architecture, in my opinion, and I choose not to pursue it. There's nothing CGI-RPG can provide that I can't get through servlets or JavaServer Pages. My opinion stands. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.