Web Server Considerations

To take full advantage of the PL/B Web Server, the programmer should:

Remember that there is communication link in the process particularly if using the Internet. The web can sometimes provide outstanding performance while other times it may not.

Pay particular attention to the server configuration. Individual servers responsible for specific applications may lead to improved performance.

Since the Windows help engine knows nothing about the PL/B Web Server, application help must be implemented using an alternative solution. An example of such a solution is available on the Sunbelt Forums.

The server uses buffering technology to maintain quality performance. The application programmer should design programs destined for the web server with that technology in mind.

Note the Following:

1.   The PLB Web Server execution is optimized to minimize the network message traffic when possible. As a program is executed, the server detects what instructions can be buffered and what instructions require immediate action. Instructions may be buffered until either the message buffer is overflowed or until a non-buffered instruction is encountered at which time a single message is sent to the client. This technique minimizes the number of messages sent between the server task and a client.

Any statement that does not return a result or any error will be buffered. These include such statements as:

DISPLAY, SETMODE, WINHIDE, WINSHOW, WINERASE, WINREFRESH, ACTIVATE, CHECKITEM, DEACTIVATE, DELETEITEM, DISABLEITEM, DRAGITEM, ENABLEITEM, DESTROY

The following statements are always buffered for all GUI objects except for COLLECTION objects:

EVENTREG, INSERTITEM, SETITEM, SETPROP, and object methods with no result returned

2.   The GETITEM statement is optimized to allow buffering. When multiple GETITEM statements are grouped together, the multiple statements are buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks.

3.   The server is designed to execute most PL/B programs with minimal or possibly no changes. However, PL/B program techniques that appear to work well while using PLBWIN on a single workstation may not provide the best performance for a PLB Web Server. Avoid creating unnecessary objects and preloading object data that may only be used occasionally. Be aware that using PLFORM and FORMLOAD objects can also be more efficient than using individual CREATE operations.

4.   The CREATE statement is optimized to allow buffering. When multiple CREATE statements are grouped together, the multiple statements are buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks. This type of buffering does not occur on the creation for WINDOW objects.

5.   The PLB Web Server must be installed on a server before it can be used. The number of client connections that can logon to the server is controlled by the authorization number specified during installation. The licensing is by connections and not by users. A single workstation running three client browsers counts as three connections.

6.   The GETPROP statement is only buffered when the SETMODE *SRVBUFMODE keyword is set to a level 2. This mode allows a group of GETPROP statements to be buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks. The SETMODE *SRVBUFMODE=2 works in a one shot manner. Once a user has verified that a group of GETPROP instructions does not have any interactions that can cause unexpected results, a SETMODE *SRVBUFMODE=2 statement can be executed immediately prior to the first GETPROP statement in a group. Once the group of GETPROP statements have been sent to the client, the SETMODE *SRVBUFMODE reverts back to a previous level when a PLB instruction other than a GETPROP is encountered. The user application must execute another SETMODE *SRVBUFMODE=2 when there is another group of GETPROP instructions to be sent as a group.

7.   KEYIN and DISPLAY instructions are deprecated for PL/B Web Server operations. These instructions are only implemented to allow legacy programs to execute without encountering an execution error.

8.   Unsupported PL/B instructions:

CLIPGET

CLIPSET

DRAGITEM

GETFNAME

GETSTRING

PAGESETUP

PARAMTEXT

PRTPLAY

SETWITITLE

SNDCLOSE

SNDOPEN

SNDPLAY

SNDRECORD

9.   Limited PL/B instructions:

COPYFILE - Server side only

Printing - Server side only

STREAM - No support for *STDOUT and *STDIN

PRTOPEN - Server side only using ‘pdf:’. If the '!' character is used as the leading character in the {device} string, an U67 error occurs.

PRTPAGE - Server side only for ‘pdf:’ support

10.  Unsupported Objects:

ANIMATE

AUTOMATION

CONTROL

CONTAINER

CHECKGRP

DIALOG

HSCROLLBAR

MOVIE

NETCONTROL

NETOBJECT

RADIOGRP

RICHEDITTEXT

VARIANT

VSCROLLBAR

11.  The ACTIVATE instruction as originally implemented depends on specific Windows OS states and events that allow the default object events to occur with specific event results. Using a PWS runtime, the ACTIVATE {object} instruction implementation is based on the EVENTREGISTER events which best match the expected ACTIVATE default event behavior. The ACTIVATE default events for PWS objects are defined as follows:

EventRegister events used for Activate Default Events:

12.  Since the PWS ALERT cannot simulate the indeterminate behaviors of the Windows OS 'MessageBox' used for the PLBWIN ALERT instruction, the PWS ALERT is being changed to clear all PLB user events in an attempt to force consistent behaviors for the different client browser types. See the PL/B Language Reference 'ALERT' instruction notes for more information on the use of the ALERT instruction.

13.  The PWS DATALIST implementation has been changed to use a HTML TABLE object instead of using the HTML SELECT object. The new PWS DATALISTis implemented as a virtual GUI object where all data items are maintained on the PWS server side to give the best possible performance when using a large number of data items in the DATALIST. The following notes describe the usage and changes for the new PWS DATALIST implementation:

1. The PWS virtual DATALIST has been implemented to provide more consistent presentations across all client browser anx iOS types while giving better loading performance for a large number of items. The virtual DATALIST cannot and does not support all of the behaviors of the Windows DATALIST control. While some keyed operations for the PWS DATALIST can work using a client browser, these same keyed operations will not work for an iOS device because there is no keyboard.

2. Microsoft does not document all of the specific behaviors of the Windows DATALIST control and the PWS virtual DATALIST provides the basic behaviors that can work across all client UI environments. Therefore, the PWS PLB program may require additional changes to overcome and allow the PWS client user to more easily manipulate PWS DATALIST items in all client UI environments.

3. The PWS virtual DATALIST is implemented using the HTML TABLE object. The different client browser types implement keyboard key combinations to achieve specific browser behaviors. The client browser keyboard key combinations may give unexpected behaviors and visual changes to the HTML TABLE items as compared to a Windows DATALIST control/.

4. PWS virtual DATALIST supported behaviors:

 

Simple DATALIST	Client Browser	iOS
Home key	Yes	No
End key	Yes	No
Down arrow key	Yes	No
Up Arrow key	Yes	No
One item selecton	Yes	Yes

 

Multi-Select DATALIST	Client Browser	iOS
Home key	Yes	No
End key	Yes	No
Down arrow key	Yes	No
Up Arrow key	Yes	No
One item selecton	Yes	Yes

 

Extended DATALIST	Client Browser	iOS
Home key	Yes	No
End key	Yes	No
Down arrow key	Yes	No
Up Arrow key	Yes	Yes
One item selecton	Yes	No

 

5. By default the new virtual DATALIST is being rendered by the PWS runtime. However, a new 'PLBWEB_VDATALIST={on|off}' keyword can be used to force the PWS server to render the DATALIST using the original HTML SELECT object support. See the PLBWEB_VDATALIST keyword description for more details.

6. The virtual PWS DATALIST is much faster than the older DATALIST implementation when loading a large number of data items.

7. The virtual PWS DATALIST supports the TABSTOPS property. When using the TABSTOPS property, the PWS DATALIST must use a fixed font. The original DATALIST could not support the TABSTOPS property.

8. The virtual PWS DATALIST supports the following methods: SetTopIndex, SetCaretindex, TabStops, AllowEmptyTab, PreventKeyClickEvent.

9. The virtual PWS DATALIST allows the object to be fully disabled as expected for a Windows control. The original PWS DATALIST could not be fully disabled.

10. The virtual PWS DATALIST has a data item limit of 65,000 data items. Under normal circumstances, the use of a very large number of data items is not practical for a PWS PLB application. However, the new PWS DATALIST implementation gives the best possible performance when loading the data items.

11. The virtual PWS DATALIST gives consistent presentation and behaviors across all client browsers and iOS devices. When using the older\original PWS DATALIST on an iOS device, the iOS forced a look and behaviors on the HTML SELECT object that could not be controlled by the PWS runtime operations. This resulted in strange unexpected DATALIST usage on an iOS device. The new virtual PWS DATALIST looks and works as expected on an iOS device.

12. The virtual PWS DATALIST is implemented to automatically invoke both horizontal and\or vertical scrollbars by the client browser for the HTML TABLE object. The original PWS DATALIST does not invoke the horizontal scrollbar when a data item is to large to fit in the HTML SELECT object horizontally.

13. The 'ctrl key' and 'shift key' states are now reported in the event modifier field for a mouse click event. The event modifier for a click event is set to a value of 1 when the click event was caused by a keystroke action.

14. A new keyword named 'PLBWEB_VDATALIST={on|off}' has been added for PWS runtime. This keyword sets the PWS rendering mode to be used for all PWS DATALIST objects in a program. If this keyword is not specified in the 'plbwebsrv.ini' file, the default behavior is to use the new virtual PWS DATALIST object implementation which is based on HTML TABLE objects. If the user wants to invoke the original PWS DATALIST object rendering, the 'PLBWEB_VDATALIST=off' keyword can be specified in the 'plbwebsrv.ini' which forces all PWS DATALIST objects to be implemented using the HTML SELECT object.

15. The virtual PWS DATALIST provides the same presentation and behaviors across all browser and iOS client device types. The older\original PWS DATALIST which used the HTML SELECT object caused uncontrollable behaviors when using iOS client devices that were inconsistent with other client browser types.

See Also: Introduction