Using a custom server component
If you are using EAServer as
the component server, you can deploy a custom component that uses
methods of the generic server component interface. You can also
write a server component with its own DataWindow methods for use with EAServer or COM+.
Some advantages of a custom component
You can use a custom component to enhance:
-
Maintainability
Keep connection information on the server by specifying values
for transaction properties. -
Performance
Specify the source file and DataWindow object on the server
so that the DataWindow object is loaded when the component instance
is created, resulting in fewer method calls from server-side scripts in
the Web page. You can also improve performance by having your custom
component maintain its state.For information about changing the state property of a custom
component, see “Maintaining state on the
server”. -
Scalability
Specify the source file and DataWindow object and use EAServer instance pooling so that
the component is reused and loading the DataWindow object occurs
only once.

If you are working in the DataWindow painter and testing the
same PBL in EAServer, your PBL
might be locked when the EAServer component
loads the DataWindow. To avoid this, disable instance pooling for
the component in EAServer Manager.
After you have finished testing and editing the DataWindow object,
you can enable instance pooling.
Instance pooling provides better performance in a production
environment when a component instance can be reinitialized and reused
for multiple clients.
For information on creating a custom component that uses the
generic Web DataWindow interface, see “Creating a custom server
component in EAServer“ or “Deploying DataWindow objects
to the component server”.
Writing your own custom
component
For full control of Web generation and the state of the DataStore
object that holds the DataWindow definition and data, you can write
your own custom class user object in PowerBuilder and deploy it
as an EAServer or
COM component. Using a custom component that includes only the processing
you need can reduce the size of the client control returned to the
Web client.
The source code for the generic component is available in PBDWRMT.PBL in the
PowerBuilder code examples directory so that you can examine or
reuse it. You can modify or add to the code in this PBL or start
from scratch, using the sample PBL as a model for your own component.

The methods of the generic EAServer component
use mixed-case names and all the examples in this section use mixed
case. If you write your own server component, the methods of the EAServer component you generate
are all lowercase. However, you can change the case of the method
names in the IDL file for your component after it is deployed to EAServer. When you use your own
component, you must generate and compile stubs for the component,
and you must do this after you make any changes to the IDL.
Your server component will use methods on a DataStore object
to retrieve data and return the data and state to the client as
HTML. To get the HTML and JavaScript that represents the state,
data, and presentation of the DataWindow object, use the Describe
method:
1 |
ls_html = ds_1.Describe("DataWindow.Data.HTML"); |
To update the HTML according to user actions, use the SetHTMLAction method:
1 |
li_rtn = ds_1.SetHTMLAction(arg_action, arg_context); |
SetHTMLAction restores the state of the DataStore based on
the context passed in as an argument and then changes the state
based on the passed action.
For more information about SetHTMLAction, see the DataWindow
Reference or online Help. For information about working
with DataStore objects, see Chapter 4, “Using DataStore Objects “.
If you create your own server component and deploy it to EAServer, you must also generate
and compile the stubs. For information on generating and compiling
stubs, see the EAServer documentation.