Evaluate your GWC-JS application needs

Even if most Genero Desktop Client (GDC) features are supported in Genero Web Client for JavaScript (GWC-JS), you still have points to consider before migrating.

Before you migrate your application for the GWC-JS, examine the limitations and authentication specifics. You must modify your application to handle unsupported features. See Features and limitations.

One method of evaluating is to run the application and see what happens! If you encounter an issue, you need to determine if this is a limitation, a customization, or a bug. See Migration tips for hints aimed at helping you solve your issues during migration.

Evaluate limitations

These limitations are grouped under the headings rendering and behaviors.

Rendering
- Pop-up windows
- Customization
Behaviors

Rendering

More than likely your application is capable of displaying on a number of different display sizes and devices but an exact pixel-by-pixel match with GDC can not be expected.

If in the GDC you have sized everything to fit in a certain sized area in a monitor, there is no guarantee that it will render inside a browser tab to the exact same size. It will be close but you may, for example, find scroll bars appearing. Therefore, to ensure that your application works well on your target devices, it is recommended that you review your application's screens.

Pop-up windows

The GWC-JS is a Web client and as such it is not a fully-implemented Windows manager. It displays at most two windows at once. It always displays the top most normal (non-modal) window, and then if there is a modal window opened, it is displayed over it. This is the equivalent of running the GDC with every non modal window maximized.

If you have a situation where window B is opened over the top of window A and there is useful information that needs to be seen in window A, you should consider opening window B as modal. This can be accomplished by referencing the default.4st window style and setting the attribute STYLE="dialog" in the Genero BDL code:

OPEN window msg WITH FORM "MyWindowB" ATTRIBUTES (STYLE="dialog")

Window B then displays as a pop-up window.

An alternative is to consolidate windows A and windows B together as one window.

If you already have some pop-up windows in your GDC application, in the default.4st set the windowType style attribute to modal in the Genero style for Window.dialog to achieve a similar display with the GWC-JS.

Note: Any style (4st) element bound to a Window may contain the windowType attribute.

Excerpt from

$FGLDIR/lib/default.4st

<Style name="Window.dialog">
  <StyleAttribute name="windowType" value="modal" />
  <StyleAttribute name="sizable" value="no" />
  <StyleAttribute name="position" value="center" />
  <StyleAttribute name="actionPanelPosition" value="bottom" />
  <StyleAttribute name="ringMenuPosition" value="bottom" />
  <StyleAttribute name="toolBarPosition" value="none" />
  <StyleAttribute name="statusBarType" value="none" />
  <StyleAttribute name="errorMessagePosition" value="popup" />
</Style>

Multiple Document Interface

Multiple Document Interface (MDI) is not applicable for Web applications.

Customization

It is likely you will want to apply some corporate styling to your user interface, for example, to use your corporate colors, add your logo, etc. For more information on this, please see the customization topics in the How Do I … ? section. Before you migrate your application to the GWC-JS, it is recommended that you try out some customization exercises. For example, change the default blue color of the user interface to a color of your choosing, and/or modify the header to display a logo, and/or change the favicon.

Behaviors

With the GDC, your application is an executable running on a front-end PC. It is therefore bound by rules of what an executable can do within the operating system. With the GWC-JS, your application is running inside a browser. As such it follows the rules of what Web pages are allowed to do inside a browser.

As the Web browser is more vulnerable to intrusive attacks, you need to take into consideration what control you, as the developer, have over how accessible and secure this environment is, and how safe data is. If you find the browser too restrictive, consider what a malicious Web site would do if it could:

do file transfer without user permission
perform front-end calls to your disk
access APIs on your system
print immediately to the local printer

This section recommends ways to perform these tasks with security in mind and suggests alternatives to perform them safely from the GWC-JS.

File transfer

File transfer in GWC-JS is not transparent. The browser requests user permission before downloading anything on the client side. For more information see FILE_TRANSFER.

GDC front-end calls

Calls by the front-end that access the desktop file systems (disk) are not supported. Check the available front-end function calls for GWC-JS in the Genero Business Development Language User Guide. The alternative is to write your own front-end call in JavaScript. For more information see the Implement front call modules for GWC - JavaScript topic in the Genero Business Development Language User Guide.

GDC embedded APIs

APIs such as WinDDE, WinMail, and WinCOM used for data exchange and communication with, for example, Microsoft^® Excel^®, Word^®, and Outlook^®, are not supported by GWC-JS. The alternative here is to use the server-side Java API solutions for Microsoft^® documents, such as those provided by Apache^®. For more information, see the topics about the Apache POI framework in the The Java interface section of the Genero Business Development Language User Guide.

Printing to local printer

Printing immediately to a local printer is not supported. The local printer has to be registered on the server first and print commands must originate from the back-end server. Alternatively, you can display a file that the user can print by selecting File > Print menu in the browser.

Keystrokes

Some browsers may not allow some or all keystrokes to pass through to the application, or it is possible (as in the case of tablets and smartphones) that the device does not perform keystrokes. You should review your sources and review your dependencies on keystrokes. For example, use ON ACTION instead of ON KEY, etc.

Also it is recommended to review the text messages displayed on the screen. For example,

Press <ENTER> to continue

If you have messages like this displayed on your screens, text may need to be made more appropriate for the application.

License count

Our intent is for your GWC-JS to use the same number of licenses as a desktop application. However, there are two cases where you may observe a difference.

If you close a browser tab or a browser window, it does not send a signal to the fglrun process to stop. It will continue to consume a license until a timeout period (default 5 minutes) is reached.
Note: Even though the same occurs if you close gdc by killing its process, it is more probable to close a browser tab then it is to kill the gdc process.

If you have a low number of licenses or run close to your limit of user licenses, you may need to add extra licenses to lessen the chance of running out of licenses when this happens. With a CPU license this is not an issue. For more information see Multi-user Licensing topics in the Genero Licensing User Guide.
We can identify that a program has launched another program via RUN (or StartMenu) commands. This results in the same license being used with no extra consumption of licenses. However, if you type an application URL into a browser or click on a link, there is no way of matching that up to an existing Genero program running in a browser and/or on the same PC. If you use a third party menu system, you may find that your license consumption increases if users run multiple programs. If you use a third party menu system, either use CPU based license. For more information contact your local sales office.

Evaluate authentication

Most GDC applications connect to the server with its user permissions and profile. As a result, the applications are run under this user identity.

When applications are deployed through GAS, they are launched as the user that started the GAS, unless you ask GAS to impersonate.

As the application user is different, this can have an impact on use of environment variables and permissions. The setting for the HOME environment variable, for example, may not be for the user you intended, and the ability to read/write files and execute sub-shells may also be affected by different user permissions.

You need to review your sources to determine how dependent you are on environment variables. If you do not already have one, it is probable that you will need to add the concept of an application user to your application. You will also need to consider how this user is authenticated. This may mean adding your own login/password dialog, or using SSO or Web server authentication.

In any case, it is recommended to migrate the application first on GDC over HTTP. If the application runs on the browser, no further action is required. Otherwise, depending on authentication needs, adaptations to your application may be needed.

Single sign-on (SSO) authentication: The Single sign-on (SSO) authentication mechanism now works for both Genero Desktop Client (GDC) and GWC-JS. If you were using SSO with GDC, you can continue to use it with the GAS. See How to implement Single sign-on (SSO) for more details.
Web Server authentication: Web servers such as Apache^® or Microsoft^® IIS provide simple authentication mechanisms that can be used for authentication. If you use the Web server's authentication mechanism, the login details are transmitted to Genero applications by the dispatcher in an environment variable. The user login can be retrieved from the runtime environment with the FGL instruction:
fgl_getenv("FGL_WEBSERVER_REMOTE_USER")
For more details, see the fgl_getenv topic in the Built-in functions chapter of Genero Business Development Language User Guide.
Application login: With an application login, there is nothing additional to do as the application handles the login.