RE: Who's doing Web work on iSeries? (was: ASP on AS/400 Apache) -- WEB400

> From: Joel R. Cochran
>
> As a matter of personal preference, and the main reason I don't care for
> webfacing and such, is that I do not think that most 'traditional' RPG
> screen and program designs translate well into HTML/CGI.

Now, take my response with a grain of salt as well, because obviously I'm in
the business of converting traditional RPG programs into web applications.

> You have to think
> differently when designing a web page with RPG than a Green Screen.

Or, you can think differently about how you approach your web application
design <smile>.


> Let's take the traditional Green Screen Maintenance program.
(snip)
> Now, that's 6
> screens, probably all in the same DSPF, so really 6 screen formats and a
lot
> of RPG code to navigate them, but you typically run them all through one
> program.

I'm not sure about six formats... most people I know do this in two.  But I
understand the point.


> The formula in HTML with CGI is 1 screen = 1 program.  At first
> this sounds
> horrible, but you realize immediately you are not limited to
> 24x80 anymore!
> You can scroll, have popups, open seperate windows, and all kinds
> of stuff.

This works very well for what I think of as "data mining" applications,
where the idea is to display data in various ways.  This UI design doesn't
work as well that for data-intensive operations, where the idea is to key
data in as quickly as possible.  Point and click is great for inquiries, but
nothing beats tab and function keys for data entry.


> But you have to think and design differently to make it all flow properly.
> The other thing to remember as well is that unlike the green screen world
> you are familiar with, some things can no longer be taken for granted.
>
> A big number 1 on this list is that the System no longer knows
> who you are.
> The request comes in, the page is built, the page is delivered, the server
> forgets everything it ever knew about you.  There are no inherent
> sessions.
> Every new request has to 're-educate' the server about who it is
> requesting
> this data.

Only for client/server architectures.  If you instead write server/client
code, where the application program determines the screens to display and
gets back the response, then the standard design philosophy we've used for
so long still works.  And many people find this to be the best way to design
data entry applications.  For example, the flow of an order entry
application may be:

1. Select customer
2. Enter ship to information if required
3. Enter items and quantities
4. Post order

This is NOT the best paradigm for an Internet storefront, but it's the best
way for a data entry clerk to enter data.  And that's the primary difference
between enterprise applications and Internet applications; enterprise
applications are designed to be streamlined to reduce entry time for
experienced operators, while Internet applications are designed to be easy
to use for novices.


> Which leads us to another thing... you are no longer writing code
> to produce
> your output.  You are now writing code to write code to produce
> your output.
> That throws a lot of people for a loop when they are first starting with
> CGI.

With JavaServer Pages as the primary interface, you spend very little time
writing this type of code.  That's why I prefer it to raw CGI.  CGI that
uses a lot of service modules to format the data is better, but in the end I
don't want my application programmers to worry about, or even have to know
about, cascaded style sheets or HTML tags.


> All I'm saying is that I personally think that your heartache will be
> greatly reduced if you don't think of it as a 'migration', but instead
> approach it as a redesign.  The bulk of your code can still be cut and
> pasted into your new programs, but there will probably be a whole bunch of
> small ones to replace those old large ones!

All the above being said, there is definitely a need for what you're
suggesting.  That's what I suggest in my book (eDeployment: The Fastest Path
to the Web).  The long term approach should be to modularize your programs
so that your business logic s encapsulated into servers.  However, most
companies don't have the time or resources to do that to their entire
business flow, which is what is required if you use a total redesign.
Instead, you need a staged approach, where you first get your UI in place,
and then rewrite the modules underneath as time and resources permit.  Of
course, that's my opinion because that's what our tools do - we can quickly
(in a matter of days) get an application on the web, and then provide you
the tools to redesign your applications using a client/server approach that
encapsulates your business logic.

But that's just our way of doing things <smile>.

Joe Pluta
Pluta Brothers Design
www.plutabrothers.com