RE: Aaron Bartell's RPG/Java comparison

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> Isn't the ability to change presentation really something that flags or 
switches is good for?
---------
That's not what I'm talking about.  I'm talking about fundamentally changing 
the look and feel of an entire application by simply changing the adapter or 
decoration classes.  The most extreme example of this is the "look and feel" 
capabilities of Swing.  With a single line of code, you can change your entire 
UI from a Windows-like presentation to a Motif-style, without changing a single 
line of application code.  This is all done through subclassing, not through 
switches.  Testing switches is inherently a bad technique, and good OOP 
practices remove most IF statements.


> Object oriented programming has nothing to do with 
flags and switches and controlling the presentation. 
---------
I have to agree with you here.  Except that flags and switches shouldn’t be 
used at all to control the presentation.  UI issues should be handled by 
adapter classes.


> One of the reasons I'm playing with servlets now is to try and duplicate an 
application (or part of an application) I wrote in RPG for displaying 
customer service data on the web. The presentation is completly controlled 
by the URL and at a lower level the account number signed on with. In other 
words, the same program will look like an office depot site for office 
depot, and it will look like Kmart for Kmart. All by the URL and a few 
"flags and switches". At the account level, each account has the ability to 
control what data is displayed, in what order, if the particular column is 
sortable and/or searchable, and what the heading of each column is. (hard 
to explain, there's a TON to it). 
---------
It's not hard to explain at all, Brad.  This is the same type of "user state" 
as used in most decent websites these days (My Yahoo, My MSN), and nearly all 
desktop applications – the ability to customize the UI.   If you were to use 
JSPs rather than CGI, your changes are actually trivial, because you would 
simply call a different JSP to get the logos and stuff, but the JSP would 
access data through widgets populated by the host servers.  In that case, there 
are NO switches; it's simply a hierarchical tree of URLs.


> It's a total of 4 RPG programs (no more than a couple hundred lines average) 
and a few service programs (I consider service programs similar to Java APIs 
since no one has given the RPGers all the neat little tools, we have to 
write them ourselves).
---------
Service programs are "similar" to Java APIs, but much less powerful because 
they don't support inheritance.  For example, I've currently got about a 
half-dozen widget classes based on my AbstractTableWidget class (one displays 
query data, one displays fields from a record, one displays a prompt, and so 
on).  Because they all subclass AbstractTableWidget, I can always add a feature 
simply by adding a method to the AsbtractTableWidget class.  Once I've done 
that, the method is immediately available to all the subclasses, without having 
to write a single line of code for those subclasses.


Rewriting this in Java is possible, but I'm not sure 
it will be easier just because it always comes back to DB interface. RPG 
does it so much easier. 
----------
That depends on whether you're willing to do the infrastructure work.  I've got 
an entire client/server framework set up that allows me to create a database 
server for a new file in about 20 minutes.  One of these days I'll create a 
tool that will do it in even less time.  But even so, in 20 minutes I've now 
got a server, and my classes allow me immediate access to that data.  Or, I can 
use my JDB/400 classes, which encapsulate the Toolbox I/O classes and allow me 
direct access to database files with the following code:

Jdb400File parameterFile = new Jdb400KeyedFile("PARML1"”);
parameterFile.CHAIN(userid);
String userType = parameterFile.getString("PAUTYP");

But you don't get that kind of productivity without having written Java for 
years, learning the various capabilities and building your own set of tools.  
And you have to have a solid, fundamental understanding of basic programming 
architecture before you can build tools that make sense.


Writing standard output is the same, reading env. vars and standard input 
isn't much different (again given you write your own wrappers). And 
"seperating business logic from processing layer" is 99% buzzword. I've 
done it with my app as much as you can with any Java App. 
-------------
This is where we fundamentally disagree, Brad.  You might have allowed the user 
to switch from "Kmart" mode to "Office Depot" mode with a switch, but that’s a 
far cry from separation of business logic and presentation.  True separation of 
BL and UI involves the ability to quickly adapt your classes for ANY sort of 
user interface.  How long would it take to rewrite your code to present 
everything in XML?  Or to talk to a 5250 green screen, for that matter?  For 
me, my servers don’t change at all.  And for my UI, in the case of XML, I 
simply attach a different adapter class.  For 5250 UI, I write a green screen 
shell (although I'm toying with the idea of creating a user-defined data 
stream).  That's what separation of BL and UI is all about.  Handling 
unforeseen UI requirements without having to fundamentally rewrite your APIs.

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---