Strategic Java Usage/Productivity Versus RPG

Nathan/All,

Observations, IMHO and my experience embedded in your reply.



Paul,

Your file maintenance utility has inspired me.  I'm considering writing a
generic component in RPG, not for maintaining, but for browsing files.  I
can envision exporting an api such as the following:

 fileReference = browseClass_Open(Library:File:Member)

 browseClass_SetFileReference(fileReference)
 browseClass_ListFromTop(recordCount)
 browseClass_ListNext(recordCount)
 browseClass_ListPrevious(recordCount)
 browseClass_ListFromBottom(recordCount)
 browseClass_ListFromKey(key:recordCount)

 ...

 browseClass_Other()
**************************************************
Nathan,  good stuff here.  Your "browse file" component or object that your
propose building is the most common user requirement that we see in
application development with our clients.

How many applications have required these generic requirements?:

a)  Show me x fields from file y in library z
b)  Show me 10 at a time
c)  For column c use "Last Name" as the column header and ...
d)  More advanced:  Allow me to search based on field x and allow me to sort
on any field
e)  Plus several additional generic requirements

It may be a little light weight without the associated verbal description
but I've documented our approach to this "#1 Most common programming task"
in the following PowerPoint:
http://www.planetjavainc.com/pres/AdvancedJavaDesignPatternsInWeb_files/fram
e.htm  (specifically in the "select and display section")

Again, it is our view/goal to automate this #1 redundant requirement into a
generic component that can be used regardless the specific
library/file/member you are "browsing".   If we can do that, we have
shortened the time required to develop applications significantly.

A few features from your api that may need to consider are:

a)  Fields to display?  Often, files have 100's of fields and requirements
often state show me fields (a, c, d , p, and r).  Perhaps adding a parm to
your "browseClass_Open(Library:file:member:field1, field 2, field 3, etc)?
This allows the api user to state dynamically, what fields they want to
display in their result.

b)  Associated with the generic browse requirement, is the need to allow the
user to specify "runtime dynamic selection" to the browse.  For example, if
browsing an INVOICE file, the user often wants to be able to specify "Find
Invoice By Number" and then they supply the invoice # at runtime.  So your
api may have "browseClass_setSelectionFields("INVOICE_NUM")"  Obviously your
design must support multiple selection fields with the array of conditions
support such as "INVOICE_DATE > ? and CUSTOMER# = ? or /and ...."  This is
kinda like a generic QUERY/400 component with dynamic prompt.

c)  The other huge need is to support specific requirements based on each
field being displayed.  For example, if your browse file facility is showing
a salary field you would want to apply current formatting or if browsing a
employee department field, you may need to supply a F4 (prompt) to allow
selection of a specific department.  Other "field" specific characteristics
include:  column header, possible values (f4), formatting, authority to
view, update, links or associations to other data (set lower limit and chain
to an associated file).  This is kinda like what DDS allows you to specify
but you really need more intelligence with your fields to be generic yet
powerful to a wide range of applications.

d)  When returning your record set from your api, you also need to know if
there are more records so you can generate the "next page" feature, etc.

e) actually several more generic parms to support here....
***************   </end generic "browse file" component >




**********  From Nathan***************
I don't think I'd want to bite off generic add, change, and delete
procedures, because such actions are generally subject to complex business
rules that would need to be overridden and adapted to individual
circumstance anyway.
*********  end Nathan *********


<Business Rule Design for Complex individual circumstances>

   This is an excellent scenario to further explore OO and it's capabilities
in terms of productive application development.   Actually we an accommodate
these complex business rules rather easily and quickly.

   This is nearly impossible (IMHO) to design completely generically
although we can generically do most all of it.  However, most applications
and businesses have unique and "unpredictable" rules that apply when a)
Adding a new record  b) updating a record c) deleting a record, etc.....

For example: assume a typical set of business rules in a HR application:

a)  Employees that are "MANAGERS" cannot be updated by this application,
they are handled by process "Z" so DON"T ALLOW MANAGERS to be edited.
b)  Also, validate that any "NON-MANAGER" employees cannot be assigned a
salary > 125000 "   Our company's compensation policy restricts salaries to
this limit.  and blah blah blah...


So, the requirement in this case is to allow "employee data" to be updated
but restrict the updates to these conditions...

The code to generically update a record can be fairly easily written and
inherited for EVERY file in EVERY database and we simply allow specific
complex business rules to be specified for this particular database record
for "ROW" by overriding the generic insert, update, and delete methods.

For example:  I enhanced the Java400 demonstration application at:
http://www.planetjavainc.com/wow60/runApp?id=298

to support these features:  a)  In the "Employees" operation only return 10
records at a time    b)  Don't allow editing (see edit icon to the left of
each data row) if the employee is a "Manager" or his name is "Nathan"   c)
When updating a Row, disallow updates if the employee is not a manager and
an attempt is made to set the salary > 125000

This is a small example of complex business requirement.

The net is this:  The general behavior of insert, update, delete is common
for any relational database record;  a framework should allow this default
behavior but you MUST allow specific "non predictable" business rules to be
enforced.  This requirement was enabled basically with 2 "IF " statements
and 2 minutes of development time as shown below;  Everything else needed to
update, insert, delete is inherited:

Java class to enforce business rules:

package PlanetJ.example;

import PlanetJ.DataEngine.exception.*;
import planetj.DataEngine.*;

public class Employee extends PlanetJ.database.Row {

/**
 * Check to see if this Row may be edited.  By default, all Rows may be
 * edited.  Subclasses may override to implement a different behavior.
 *
 * @pram ec  context in which application is executing.
 *
 * @return  true if Row may be edited; false otherwise.
 */
public boolean isEditable(ExecutingContext ec) {

        try {

                // If the employee is a Manager or Nathan (just an example)
don't allow the Row to be edited
                if (getValueAsString("JOB").equalsIgnoreCase("MANAGER") ||
getValueAsString("FIRSTNME").startsWith("NATHAN")) {
                        return false;
                }
                else {
                        return true;
                }
        }
        catch (Throwable t) {
                t.printStackTrace();
                return false;
        }
}
/**
* Validate if the operation can be performed on this Row.
* <p>
* @param: int pOpteration Constants stored in Row  ie. Row.INSERT
* @param: java.security.Principal pUser
* @exception DataEngineException if a this any field is invalid.
*/
public void validateRowOperation(int pOperation, java.security.Principal
pUser) throws DataEngineException {


                switch (pOperation) {
                        case (INSERT) :
                                // Whatever you want to validate on insert
                        case (UPDATE) :

                                { // If the employee is a Manager they can't
have a salary > 125000
                                        if ( (!
getValueAsString("JOB").equalsIgnoreCase("MANAGER")) &&
getValueAsDouble("SALARY") > 125000) {

                                                throw new
DataEngineException("Hey they ain't worth that much! Lower that salary!");
                                        }

                                }

                        case (DELETE) :
                                // Whatever you want to validate on delete
                        case (COPY) :
                                // Whatever you want to validate on copy
                }
        }


}

********************************


This design approach is shown here:
http://www.planetjavainc.com/html/demo.html

You can edit the application here:
http://www.planetjavainc.com/wow60/WOWBuilder
Use userid:  "support@xxxxxxxxxxx"  and   password "support" to logon then
go to step 3 setup operations.   NOTE:  this is on on of our development
systems; it might go up and down a few times a day for software updates....

NET:  We are after productivity.   We now have a much more complex business
application with specific rules enforced but have only spent about 15
minutes total on the application.

</end>



















There are more similarities between ILE and OO languages than most people
realize.  For object instantiation in RPG:

 Eval myInstance = myClass_New(parameters)

 Callp myClass_doSomething(myInstance: parameters)

Where myInstance would be a pointer to a data structure containing instance
properties, which would be referenced from myClass procedure calls.

For inheritance in RPG, create a new module, either importing and wrapping
the procedures in a base module, or create a new module containing just
procedure overrides, then bind to both modules.

For polymorphism in RPG, define data exports in modules, supplementing
procedure interfaces, which alter the behavior of procedures based on data
content.

It's true that most RPG programmers wouldn't consider following OO design
patterns, unless they first immersed themselves in OO languages for a period
of years.  But I returned to RPG for both performance as well as
productivity reasons.

Nathan.