Re: Customizing Webfacing screens?

Hi Glenn!

>Is there a relatively easy way to make the lines 
>of a subfile into pushbuttons using Webfacing? 

I don't think so, mostly because a subfile with an option field can allow
multiple choices, a la PDM: I can put a 4 on these three members, a 3 on
that one and a 6 on that one before I press Enter.  A pushbutton wouldn't
work in that scenario.  Because WF works only with the display panels, it
can't divine the intent of the RPG code that processes the screen.

>I finally got my few screens to work, but they
>act too much like 5250 screens displayed in a 
>browser for my tastes. If I am going to web-enable, 
>why not make the interaction feel like an 
>HTTP screen?  I was hoping for a magic bullet, but 
>in my opinion, this tool is not it.

There is no magic bullet.  WebFacing is great if you have to automatically
convert DDS to the Web.  Automatically, meaning that you don't need to
re-work each panel after conversion and you don't need to modify the
underlying code.  Convert and go.

>I have done other projects with Net.Data and a little 
>test using "e-RPG" to handle cgi scripting, and for all 
>the overhead of Webfacing, I see very little benefit.

The benefit is that you don't have to touch anything after the conversion.
Well, almost nothing.  I ran 5000 panels through the tool and they all
converted and ran on the web.  Slower than 5250, but they all ran first
time.  No screen scraping tool I know of has that record on our panels.

The catch is that you just can't change the UI of a 5250 application from
5250 to HTML and be done with it.  In order to keep the application working
as-is, you somehow need to mould the HTML so that it behaves like the 5250
panels.  That includes command keys and mode-aware operation.  By
mode-aware, I mean that if your 5250 app takes 3 screens to enter an order,
those 3 screens might be processed by 3 separate HLL programs.  That means
the web version needs to present panels to the same 3 programs.  No 'browser
back' buttons allowed: if the user wants to move from pgm2 back to pgm1 they
need to click the F12 button.  But that isn't very webbish, is it?  There's
the conundrum.  If you want to keep the back end intact, you can't drift too
far from the flow of the back end.

The more you are willing to tinker with the back end, the freer you are to
make the front end more web-like.  Just don't expect an automated conversion
to be able to do that for you.  I would use WF as a means to getting the
application truly web-enabled.  You can convert the thing today, deploy it
and have the end-users start with it.  As feedback comes in, you can then
get to work constructing the enhanced version, either in Java calling
back-end service program procedures or CGI or whatever works best for your
organisation.  You can then parallel the existing functionality with the new
stuff.  Since you've already got operational experience with WAS, you won't
have to learn that over, and you can move ahead from there.

Is WF perfect?  Nope.  But I think that it has a place especially if time to
market is a pressing issue.
  --buck