|
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
As an Amazon Associate we earn from qualifying purchases.
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.