This post discusses how you can integrate WebUtil with Designer 10g to generate webforms using the webutil API’s with less post generation actions.
Near 100% generation of webforms using Designer 10g is archievable. Specially if you have a good set of object libraries and templates. Integrating the WebUtil object library into your set of application object libraries and templates is another thing. Default, after generating a forms module that incorporates webutil functionality requires post generation steps. These steps typically involve dragging the webutil object group to the forms module and changing the default calls to host.
The easiest way to integrate WebUtil into your forms application is to make a copy of your template(s) and drag the webutil object group and the webutil PL/SQL library into the template. This is easy, but the number of templates doubles with is not desirable to maintain.
Designer offers a more elegant way of doing this via the Generator Preferences. Via the OLBLST preference in the Generator Preference Window you can enter a comma separated list of module level source objects and object groups in object libraries which will be subclassed or copied (see preference OLBSOC) into your webform module during generation of the forms module.
The module level source objects are are searched in the (comma separated) list of object libraries you entered in the STOOLB property. Figure 1 show this in detail. The sy_* references my application templates/libraries. As you can see by the yellow icon the preferences are added at the module level because incorporating webutil is at the module level: you do not want all of your modules to incorporate the webutil beans and objects, just the one’s that require webutil functionality.
Figure 1: Standards – generator preferences
After setting the preferences showed in figure 1, Designer will automatically incorporate all required WebUtil functionality into your module. Without having to drag objects to your generated module afterwards!
Further, you can change the code that Designer generates when calling host commands via the menu generate options. In figure 2 you can see that I have altered the default host commands to the WebUtil equivalent (without blocking the application).
Figure 2: Menu – gen options
Because I would like this behaviour for the whole application I’ve changed the preference at the preference set level.
Now you can concentrate on writing the PL/SQL code that incorporates webutil functionality without the hasle of makeing post generation changes. There remains one thing I could not automate via preferences: the creation of the user defined trigger that is necessary for asynchronous uploading used by the webutil_file_transfer functionality. I think the most elegant way of adding this trigger to your forms module is to change the webutil object library and add the user defined trigger it to the webutil object group. Actually, it would be very nice if the webutil team incorporates this enhancement in their next release of webutil. The code that is fired from within the trigger is in essence an if-then-else statement calling one proceduce when upload was succesfull and another procedure when the upload was unsuccessfull.
Another enhancement of WebUtil would be, in my oppinion, that the exceptions in the client_ole package are NOT handled inside the WebUtil functionality, but throwed back to the developer, so that the developer can handle the exceptions him-/herself.
