RE: Re: Resort back to RPG?

Nathan,

I forgot to say, in response to your comment in an different thread that OO
programmers spend most of their time writing Class definitions and objects
and stuff (SERIOUS PARAPHRASING, Nathan was much more articulate!)... I
agree!

I spend a lot of time developing the wrapper objects for files and other
various and sundry classes.  These classes become packages, which then are
used in whatever application I see fit, either for the web, as a server
program, or in a full GUI.

Think of these packages as Service Programs... Service Programs that provide
database integrity, guarantee the business rules are followed, and create a
consistent basis from which to develop new application features.

If done properly these packages are developed once, so like all good
long-term software projects the bulk of the effort is put into place
up-front, at the design stage, where it belongs.  Now for future development
I simply rely on my tried and true packages, maybe adding a class here and
there if I happen to come across something I missed or need to add.

:-)

Ciao,

Joel R. Cochran
Director of Internet Services
VamaNet.com
(800)480-8810
mailto:webmaster@vamanet.com


> -----Original Message-----
> From: Joel R. Cochran [mailto:jrc@masi-brac.com]
> Sent: Wednesday, July 17, 2002 3:21 PM
> To: 'web400@midrange.com'
> Subject: RE: [WEB400] Re: Resort back to RPG?
>
>
> Hi Nathan,
>
> It's difficult to answer your questions since this is a
> project still in
> development, but I'll do my best...
>
> > The number of:
> > - database tables and views
>
> I have about 30 files in our database, each one is fully
> encapsulated in
> it's own wrapper class.  All access is handled through these classes:
> selecting, updating, deleting, and inserting each have their
> own methods
> with their own SQL statements.  Every variable is accounted
> for complete
> with it's own getter and setter methods.  All the nitty
> gritty JDBC stuff is
> handled in a single class called DBAccess.  Any class that
> wants to connect
> to the current database simply instantiates DBAccess and
> retrieves it's
> connection for use with it's SQL statements.
>
> To me the Views issue is no big deal thanks to the magic of method
> overloading.  You could have a method for the standard view
> and/or a method
> that accepts a String that is the "ORDER BY" parameter, and
> then use it like
> so where VMADDR1 is the field name to order by...
>
> MyDBFileObject object = new MyDBFileObject();
> object.select( "VMADDR1" );
>
> The next step would be to define each of the database field names as a
> constant in the wrapper class and then refer to that constant name:
>
> public static final String ADDRESS = "VMADDR1" ;
> ...
>
> MyDBFileObject object = new MyDBFileObject();
> object.select( MyDBFileObject.ADDRESS );
>
> Now the user does not need to know the actual Database Field
> name to order
> by, just a Constant descriptor.
>
> Want multiple selection?  No problem... overload the method
> again to accept
> an array of Strings.
> Now when you build the SQL statement, simply read through the
> array and add
> each ORDER BY parameter.
>
> Simply, easy, flexible file views!
>
>
>
> > - database maintenance screens
> > - database inquiry screens
>
> This is an interesting question, one I'm not sure exactly how
> to answer.  I
> consider it apples and oranges between a typical green screen
> program and
> the potential of a full GUI.  I have one GUI shell program.
> Inside it I
> create and display different components depending on current
> user action.
> They can be seen simultaneously, overlapping, independently,
> or what have
> you.  With the current design I'm building, components are
> created that
> contain each logical part of the database.  Sometimes that
> may only be one
> file, sometimes it may be several, but the user sees one
> unified display.
> I'm having trouble expressing what I'm thinking, but I hope
> this gets it
> across...
>
>
>
> > The number of printed reports available, and how they're generated?
>
> I'm still learning about printing: remember, this is a work
> in progress :-)
>
> I have several options here.  I can design and deliver output
> as pure text
> files, which I think is analogous to a standard SPLF.  I can
> output HTML
> complete with graphics and images.  I can draw to a BufferedImage with
> anything you could do graphics or layout wise.  I can
> probably get real
> techie and write directly to the printer itself (not that I
> have any clue
> HOW to!) but there are a whole slew of standard classes
> available to help
> with Printer output and Jobs.
>
>
> Sorry I can't write more right now...
>
> Joel R. Cochran
> Director of Internet Services
> VamaNet.com
> (800)480-8810
> mailto:webmaster@vamanet.com
>
>
> > -----Original Message-----
> > From: Nathan M. Andelin [mailto:nandelin@RELATIONAL-DATA.COM]
> > Sent: Tuesday, July 16, 2002 8:14 PM
> > To: web400@midrange.com
> > Subject: Re: [WEB400] Re: Resort back to RPG?
> >
> >
> > > From: "Joel R. Cochran" <jrc@masi-brac.com>
> > > Maybe I'm just not substantial :-)
> >
> > Joel,
> >
> > Would you mind describing the type of transactions that must
> > be entered by
> > users of your software?
> >
> > The number of:
> > - database tables and views
> > - database maintenance screens
> > - database inquiry screens
> >
> > contained in your application?
> >
> > The number of printed reports available, and how they're generated?
> >
> > It may give us a feel for what's possible in a cross-platform Java
> > application.
> >
> > Thanks,
> >
> > Nathan M. Andelin
> > www.relational-data.com
> >
> >
> >
> > _______________________________________________
> > This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> > To post a message email: WEB400@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> > or email: WEB400-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/web400.
> >
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> or email: WEB400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>