Re: Web Enabling existing form based program

HOWEVER, before we get all excited...if your Forms were not designed for the Web - you will be in for some surprises...such as strobing or non-functional menus,
windows which will behave erratically, combo box which don't work at all, network slowdown
that is not to be believed if the interface requires major mouse action...

Think of how the application server runs the forms. It runs the form on the application server and presents the interface on the client. Application code executes on the application server, but the user interface objects such as text items and poplists will generate network traffic any time the user acts on the object. One strategy is to perform validation (using the form level property Validation Unit) on the form or block level; this reduces the number of triggers that fire as the user moves through the items on the screen.

It is not reasonable to expect forms to use the same fonts, or, in some cases, colors in client/server and the Web because these are different environments. The differences in fonts could cause sizing issues - we have an application built purely in Forms which is sitting and cannot be web-deployed because of their extensive use of boilerplate text - and the fact that the Forms were developed on NT and then needed to be deployed on Solaris -....the font size skyrocketed from 10 pt to 48+ making the Forms completely
unusuable. Also, they put most of their triggers in the client - leaving the testers waiting agonizingly long minutes waiting for the app to perform basic functions.

There is a good paper by Peter Koletzke which I have passed along to some of the folks here - briefly he mentions -

"Remember - This is a Java environment not a Windows environment. The look and feel is different between these two environments.

Similarly, TEXT_IO runs on the machine that runs Forms Runtime. This is the application server in the case of Web Forms so you have to be aware that reading and writing files with TEXT_IO will manipulate files on the application server not the client

MDI Toolbars are not usable in Web Forms. If you must have a toolbar, put it on each window instead. If the form has multiple windows, copy the toolbar canvas and block and assign one canvas/block to each window.

Whenever the user moves the mouse cursor (using the Tab key or mouse) there is network traffic generated. In addition, each time the user presses the mouse button, a network packet is generated. To minimize this network traffic, avoid item triggers (and validations as mentioned above) as much as possible. Also avoid making the user click on multiple areas with the mouse, if possible. Specific triggers to avoid: KEY-NEXT-ITEM, PRE-TEXTITEM, WHEN-NEW-ITEM-INSTANCE, POST-TEXTITEM, and WHEN-VALIDATE-ITEM.

There are a few triggers that do not fire in Web Forms. Avoid using these even though they work in client/server applications. These triggers are WHEN-MOUSE-LEAVE, WHEN-MOUSE-MOVE, and WHEN-MOUSE-ENTER. These don't fire because of a limitation in Java.

Timers generate extra network traffic as a packet is sent each time that the timer expires. Also, if the user is editing text when a timer expires, a lock will occur.

Toolbar icon files or any other icon buttons, GIF files on the web, ICO files in client/server, work differently between the two environments. The icon appears centered in the button on Web Forms, while, in client/server, the upper left corner of the icon appears in button. Be sure the icons are the size of the button and this will not be a problem. Alternatively, reposition the image in the icon file when you convert it to GIF. Unix may have different icon files so and you need to convert those to GIF as well. (Our had a nice disco strobe effect though!!!)

Having many forms at the same time can cause a crash. Use CALL_FORM or NEW_FORM instead of OPEN_FORM whenever possible. Developer v.6 will fix this problem.

Key assignments are different on client/server than on Web Forms. Use the function key name, if needed, for documentation purposes and refer the user to the menu choice Help-Keys for the exact keypress needed for that function. There is a file called FMRPCWEB.RES in the EXTRAS\WEBKEY directory of the installation CD that is a text file with key mappings. Make a backup of the FMRWEB.RES file in the ORACLE_HOME\FORMS50 directory and rename and copy the file on the CD to the ORACLE_HOME\FORMS50 directory.

Multi-record blocks draw slowly. The maximum number of records displayed in a form should be a small number, like six, if that is possible for the intent of the form.

The AppletViewer runs the form in a separate window but there is no concept that corresponds to the Windows-specific MDI (Multiple Document Interface) window. Each form you open will open a new window and there is no way to include a window within another window. This means that the distinction between dialog and document windows is not important in Web Forms since there is no MDI frame.

Also, you need to set the Console Window property on the form properties palette to specify which window will show the console message area. Normally this shows in the MDI window. Developer version 6 (the next release!) will use the browser as an MDI-type window.

etc. etc. etc....

So, in other words, while it sounds really good in theory - the reality is not quite there yet - if you would like the rest of the paper - please let me know and Good Luck!!!

Chana Campos

Jason Ekamper <Jasek_at_bigpond.com> wrote in message news:7io5mn$kjo$1_at_news.cowan.edu.au...
> We are a university project team developing a web based application from
an
> existing form based application with additional modules incorporated into
> it. The entire program must be web-enabled. We have started programming
the
> new modules in PL/SQL, and are looking at an easy way (or relatively easy)
> to web-enable the existing forms.
>
> We have access to OWS 3.07 and OAS 4.0.7 to run our application on.
Between
> the 8 members of our team, 4 members have had 6months experience with
> developer 2000 and forms 5. None of us have has any experience with PL/SQL
> coding, or html development.
>
> Any information or tips on where we should go, or what the best way to
> develop this application would be greatly appreciated.
>
> Thanks
> Jason
>
>
Received on Wed Jun 02 1999 - 21:17:31 CEST