>Do you think that CGI is the right architecture to replace green-screens?

The "Pat" answer to this would be;  They both have their strengths and
weaknesses.  Even though this is the Pat answer this is also very true.  I
don't have enough fingers and toes to count the amount of times that I have
run out of room on a green screen so I make some poor improvisions.  But I
also find creating useful UI's in the browser cumbersome (mostly because I
have done a lot more green screens than browser interfaces).

I don't think that the browser is a great place to develop, yet.  The reason
I say that is because I have yet to see a well written app for the browser.
You also have to create your own "state" when going to the browser unlike a
green screen where it is a constant state.

Our company has about seven development groups, and right now we are working
on creating a state-less, normalized, file-less program structure.  We are
doing this because we are finding that our business is changing so rapidly
that we can hardly keep up, so we need to develop software for re-use, and
ease of modification.  I know people get touchy when you say that you want
to take the files out of your program, but if I access my data by doing
something like this. .

eval    Custname = CustFile_Custname(1234)
vs.
FCustFile IF    K DISK
 1234  chain CustFile
eval    CustName = CSCSTNAM

. . . I can make my programs file-less, reusable by other front end systems
needing to get at my data, and modification of the CustFile is very
simplified.  And I don't loose a lot of performance if programmed right.

Aaron Bartell



-----Original Message-----
From: Nathan M. Andelin [mailto:nandelin@relational-data.com]
Sent: Tuesday, March 26, 2002 1:37 PM
To: web400@midrange.com
Subject: Re: [WEB400] CGI Beginner


Hi Aaron,

CGIDEV2 does a good job of separating HTML from RPG.  And it's a valuable
tool.  But Justin appears to be looking for a green-screen alternative.  Do
you think that CGI is the right architecture to replace green-screens?

If so, I'd like to understand your reasoning.  And if not, I'd like to
understand that reasoning, too.

This is not an HTML vs. 5250 question.  Instead it's a question about CGI
architecture in general.  The API (even with the help of CGIDEV2).  The
interface with the HTTP server.  Performance.  Whether CGI would handle the
scope required of green-screen applications.

Thanks,

Nathan M. Andelin
www.relational-data.com



----- Original Message -----
From: "Bartell, Aaron L. (TC)" <ALBartell@taylorcorp.com>
To: <web400@midrange.com>
Sent: Tuesday, March 26, 2002 10:28 AM
Subject: RE: [WEB400] CGI Beginner


> >as well as fully working samples to download (cgidev2)
>
> I was skeptical about the CGIDEV2 stuff when I first started hearing about
> it, but then I used it.  IT IS GREAT!  It allows you to take all of the
HTML
> code out of your CGI program.  The way it works is you put your HTML in
the
> IFS(or member) and write out predefined pieces of HTML code.  So you may
> have a section of HTML code that looks like this:
>
> <AS400>head
> <HTML>
> <HEAD>Hi there /%custname%/</HEAD>
> <TITLE>TITle of the page</title>
>
> <AS400>body
> <body>
> </body>
>
> <AS400>end
> </html>
>
> Then in your CGI program you say . . .
>
> chain custno CSTMST;
> UpdHTMLVar('custname':CUSTNAME);
> WrtSection('head');
> WrtSection('body');
> WrtSection('end');
>
> . . .and the sections are written out to the browser with the customer
name
> replacing the /%custname%/ variable.  It has worked flawless for me so
far!
>
> Aaron Bartell


_______________________________________________
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.