RE: Web-Facing Tool - more thoughts

> -----Original Message-----
> From: Buck Calabro
>
> Hi Jim!
>   We're looking hard at WebFacing (getting WebSphere installed is
> a bit of a
> hang-up, but that's a local problem).  What I don't understand though, is
> how WebFacing will enable me to perform extensive modifications
> to the Java
> side separately from the RPG.
>
> If I have an application that consists of several modal displays
> (enter/validate customer, enter/validate shipping information,
> enter/validate items), WebFacing makes beans and jsps that match
> the layout.
> It has to, because that's the I/O buffer RPG is expecting.  How can I make
> this into a single non-modal Java display without breaking the RPG?
>   --buck

Excellent question, Buck.

I'm a little confused by the modality issue.  I'm going to assume that you
want to make a single form with all three data entry sections, and be able
to hit a submit button to post the whole thing.  Please correct me if you
have a different flow in mind.

In the case I outlined, you need to expose the API a level below what
WebFacing is doing.  Using the API, I would write an Adapter.  An Adapter,
in OO terms, converts one protocol to another.  I would have one protocol on
the user side (the form that allows multiple sections to be entered) and
another protocol on the host side (this protocol knows how to get to each of
the panels in the display).  For HTTP, I would have an Adapter servlet, for
a thick client I would have an Adapter proxy.

Let's take the most rigid example: where each panel, upon validation,
progresses to the next panel, with no ability to change the flow.  Once the
user presses the submit button, I would first extract from the form request
the data for the first panel.  I would establish a session with the host
program and post the first panel of data.  If it were successful, I'd then
continue with the second and third panel.  If, however, I got an error, I
would bundle the error data, highlight the appropriate fields in the
appropriate section, and return the page to the user.

This would NOT be trivial, nor would it be easily automated, but it could be
done if the APIs were sufficiently robust.

As you might guess, PSC400 supports an open enough API to allow this <grin>.

Joe Pluta
www.plutabrothers.com