| |
Document revision: 2023-12-01
Refers to WEBDLG2 version: B0830-2211 patch PE83-2311300
Table of contents
Overview
This document provides a collection of tips and hints to help migrating
existing JDLG applications to
WEBDLG2.
We would very much appreciate your feedback in case you encounter
compatibility problems, or in case you find a topic not covered here,
or if you need help migrating your application.
Please send your feedback to the
support@marxmeier.com address.
Thank you very much.
Enjoy!
The Eloquence Team
Configuration
JDLG applications are configured
via application-specific attributes and
global properties.
The WEBDLG2 eloqwebd2.app
application configuration file covers the application-relevant aspects
of these two JDLG configuration
categories.
JDLG application configuration
This list indicates how to migrate the
JDLG application configuration to WEBDLG2
(please note the remarks below):
This list indicates which
JDLG application attributes cannot or should not
be migrated because of the way WEBDLG2 works differently from
JDLG
(please note the remarks below):
Remarks:
- JDLG tokens, if present in a configuration value,
need to be revised for
WEBDLG2:
| JDLG token |
equivalent WEBDLG2 token |
| $host |
$remoteaddr |
| $port |
(no WEBDLG2 equivalent) |
| $login |
$login |
| $(VARIABLENAME) |
$(VARIABLENAME) |
Please note:
JDLG resolves a
$(VARIABLENAME) token in the
JDLG
Java runtime process on the user's system.
WEBDLG2 resolves a $(VARIABLENAME) token in the
eloqwebd2 process on the server system.
As a result, WEBDLG2 might resolve a $(VARIABLENAME) token
differently than JDLG.
- Do not migrate a -dlg command line
option (for example: -dlg $host:$port). It will be ignored
anyway because WEBDLG2 uses the
RDLG method to establish the DLG connection.
- Enabled if set to a nonzero value, otherwise disabled.
For JDLG compatibility, WEBDLG2
accepts the yes or true or on keywords.
Please note:
Other than JDLG, the DLG connection
originates from the eloqwebd2 server,
not from the user's system.
If the eloqsd server is located on the same system
with the eloqwebd2 server, or if the
connection between eloqwebd2 and eloqsd is secure,
eloqwebd2.app
TLS would add
unnecessary overhead and should not be enabled.
- WEBDLG2 provides the
Server configuration to
specify the address to connect the eloqsd server.
Other than JDLG, this connection
originates from the eloqwebd2 server,
not from the user's system.
Consequently, configuring Server
is typically not necessary unless the eloqsd is located on a remote system.
- WEBDLG2 uses the
RDLG protocol method. Other methods are not supported.
JDLG global configuration
This list indicates how to migrate the application-relevant
JDLG global configuration properties to WEBDLG2:
This list indicates how to migrate other
JDLG global configuration properties to WEBDLG2:
This list indicates
JDLG global configuration properties where WEBDLG2
equivalents are not available in the current implementation but planned
for a future release:
DLG driver type
JDLG applications might expect a
JDLG driver type, i.e., expect that
DLG GET ".driver_type" and "System.driver"
return "JDLG".
WEBDLG2 allows to configure
the driver type reported to the program. It may be set to
JDLG to make these application work with WEBDLG2.
Fonts
A web browser used to run WEBDLG2 applications almost certainly renders
fonts differently than JDLG.
This is mainly caused by the DLG font sizes specified in point units,
where the exact font size is calculated based on the screen resolution.
This calculation is often not reliable.
Also, JDLG depends on the Java font
functionality which rounds certain font sizes. On the other hand, WEBDLG2
uses the web browser's font functionality which typically renders a font
at exactly the specified size.
As a result, applications migrated from
JDLG to WEBDLG2 might display
Dialogs in an unexpected way, e.g., Dialogs are unexpectedly large, or
object fonts do not fit as expected.
In the current implementation, WEBDLG2 provides the following
eloqwebd2.app configuration
items to help solving such issues without having to modify the DLG
font attributes of the JDLG
application:
- DefaultFontSize
- WEBDLG2 allows to specify the default font size in pixel units
which typically results in a reliable Dialog raster calculation.
-
IgnoreDialogFont
- When a Dialog has the fontface/fontsize/fontstyle attributes set, the
Dialog raster is no longer calculated based on the
default font.
Activating the
IgnoreDialogFont
configuration ignores all Dialog-specific font attributes. This may help
to achive a uniform Dialog layout, i.e., to enforce that the dialog raster
calculation is based on the
default font
for every Dialog in the application.
-
FontSizeFactor
- When object fonts do not fit as expected, i.e., fonts are rendered
too large or too small in relation to the Dialog raster, the
FontSizeFactor
configuration allows to increase or reduce all font sizes by a factor.
For example, since Java rounds certain font sizes, an object having
fontsize=13 set may be rendered with a 12pt font in
JDLG, while the browser renders
the font with 13pt size in WEBDLG2.
In such a case, setting FontSizeFactor=0.923 will reduce the font
size from 13pt to 12pt, to achieve a Dialog appearance
in the browser similar to JDLG.
Please note:
This is currently a work in progress. The goal is to find a method that
reliably reproduces the Java font rendering behavior.
Once available, this may then be activated in the
eloqwebd2.app configuration.
Strict value checking
You might consider to enable
strict attribute value
checking while migrating an application from
JDLG to WEBDLG2.
This might help to prevent unexpected application behavior caused by
incorrect DLG SET attribute values.
JDLG does not strictly check
certain attribute values on DLG SET.
For example, setting the ListBox.topitem attribute out-of-range is accepted
by JDLG, but WEBDLG2 returns
DLG STATUS 660 if
StrictMode is enabled.
- Affected attributes:
-
EditText.cx
EditText.cy
ListBox.activeitem
ListBox.activeline
ListBox.columnorder
ListBox.cy
ListBox.sortsequence
ListBox.status
ListBox.topitem
ListBox.vactiveline
JDLG attribute compatibility
The attributes below are currently not functional, they are implemented
but don't have any effect (DLG SET may be ignored,
DLG GET may return zero or an empty string).
- Common attributes
-
clipboardcontextmenu, hmax, hmin, wmax, wmin
- Application
-
clipboardcontextmenu, referencepoint, referencex, referencey, scalefactor
- Dialog
-
enablereference, enablescalefactor, minheight,
minwidth, setreference, setscalefactor, yield
- EditText
-
linewrap=hard, maxlines
- Splitter
-
dividersize
- System
-
clipboard, editmode
- TabBox
-
scrollable, tabplacement (other than "top")
The attributes below (JDLG print interface) are not implemented,
using these attributes will result in DLG status 657:
- Application
-
closeprinter, openprinter, print
- System
-
defaultprinter, printcommand, printerscommand, printersfilter
|
|
