The sections in this chapter are:
Use components built into VJS to help with development. It is important to understand what the components built into VJS offer. Study the components on the tabs that apply to the type of functionality you're after. Be sure to investigate the Test tab. It contains sample components that help you to learn about database access in VJS and to test your application before it's finished. Don't overlook the Other tab. It contains several useful components, such as the Coffee Table component for dynamic data display in a grid.
Develop connected components as a unit. When you start to actually develop your application, the idea is to look for a set of components that form a functional unit. Then build and test each unit as you add it to the application. For instance, a functional unit might be part of an HTML form verifying that a text field contains letters rather than numbers. After verifying the field, the form updates another page element accordingly. You should add the appropriate components to the form and connect them to each other properly before creating the rest of the form.
Leverage off your existing assets. One of the first issues to consider is what existing assets, such as databases or other legacy code, you want to use in your application. For instance, suppose you want to connect to an existing database of users and their email addresses. In this case, you need not rewrite the database; simply create a new UI for it in HTML. With all existing assets, consider how to include them in your application without changing the asset itself.
Consider the client's environment. Another issue to consider is the client environment your end users will be in. For instance, if your user's browser has Java and JavaScript execution environments in it, you can use client-side Java and JavaScript components. Otherwise, you should use only server-side Java and JavaScript components. Not all browsers support CORBA, so don't use a client-side CORBA component unless you know the client supports it.
Strategize for performance. By creating
your UI from components that are written in HTML instead of Java, you improve
performance for your end users. Furthermore, it makes sense to process
as much on the client as you can; you improve your application's performance
by minimizing the number of trips to the server. You eliminate some trips
to the server by putting a result set from a database query onto the client
so that the users can access the data locally. However, keep the result
set to a reasonable size to minimize the time the user spends waiting for
the page to download. In addition, if you are using database cursors to
get results from a server, consider using a client-side Java component.
This component might yield the best performance because it will update
just the UI element that displays the result, not the entire HTML page.
If a component is client-side, it will execute entirely on the client at run time. If a component is server-side, it is instantiated and executes on the server, although it might also trigger events that extend to remote servers, databases, or mainframes. Some components can execute on either the client or server, depending on how you design them when you create your application. At run time, they run on either the client or the server, not both. However, some components do execute on both the client and server at run time. For instance, the component JavaScript Client Cursor on the Component Palette in VJS is considered both client-side and server-side. There are examples of each of these types of components in VJS.
HTML is client-side, so any HTML-based components are client-side components. A JavaScript component can be either client-side or server-side, depending on whether the tag <SCRIPT> or <SERVER> was used to define the component. A Java component can be client-side or server-side as well, depending on how it was defined. All server-side Java components must be instantiated by JavaScript, but client-side Java components do not, if they were defined with the <APPLET> or <OBJECT> tag.
Applications that use only client-side components
do not need to be compiled and can be previewed easily in Navigator. Applications
that use any server-side components must be compiled using the JavaScript
Application Compiler (jsac) supplied with the Enterprise Server, and then
deployed to the appropriate web server. VJS automatically deploys and compiles
your application on Enterprise Server; you don't have to do the compilation
and deployment yourself.
Client-side programming is event driven in that the code executes when triggered by a user's actions. For example, in your application you might define events, such as a mouse click, that the user performs at run time. When the mouse click occurs, Communicator acts on it immediately. Furthermore, you can script event handlers that perform actions based on these types of events. However, the scripts are interpreted and run on the client. In contrast, server-side programming is not event driven, because JavaScript is executed only when the page is served to the client. Thereafter there are only a limited number of ways the user can interact with the server, such as when a form is submitted, a new page is loaded, or a cookie is used. For more information on server-side JavaScript and cookies, see Writing Server-Side JavaScript Applications.
Here is the user scenario: A user clicks a URL to link to your application, and an HTTP request with that URL location is sent to the server. The server finds the page and sends it back to the client, where the HTML engine in the browser interprets the page starting at the top. As each HTML tag is encountered, the browser displays various elements in the page layout. When a <SCRIPT> tag is encountered, client-side JavaScript runs and is interpreted by the JavaScript Execution Environment in Communicator. If the JavaScript code instantiates a Java component, the Java code runs in the Java Virtual Machine in Communicator. If an <APPLET> or <OBJECT> tag is encountered, the Java code runs in the Java Virtual Machine.
An example of a client-side HTML component in VJS is HTML Table. It works just as if you edited the HTML source code directly using the <TABLE> tag. An example of a client-side JavaScript component in VJS is Scrolling Message. It is a banner you can put on a form to display constantly "scrolling" text. An example of a client-side Java component in VJS is the Coffee Table component. This is a table for displaying data dynamically from a data source, such as a database.
Figure 2.1 shows how the component JavaScript Check Box uses client-side JavaScript during runtime execution.
Figure 2.1 JavaScript Check
Box as it executes
In this scenario, JavaScript executes on the client
after the page has been returned by the server. This scenario shows how
two check boxes on a form can be synchronized and details only the events
related to them. A real form would undoubtedly contain many other components
as well, including a Submit button.
1. User requests URL.
The URL is either entered in the Location field of Communicator or linked to from another page. The URL is sent to the server by Communicator via HTTP.
2. Server locates page in file system.
The server in this case is acting as a simple web server, performing no additional processing beyond retrieving and returning the HTML page.
3. Server returns page.
The page is returned via HTTP.
4. Communicator loads page and generates the HTML for 2 check boxes.
The HTML page is interpreted by Communicator.
5. User clicks Check Box 1 on form, triggering a JavaScript event to update Check Box 2.
Check Box 1 and Check Box 2 are two separately instantiated objects based on the JavaScript Check Box component. In this example checking one results in the other being checked because a two-way connection was created between them at design time.
Server-side programming is not as event driven as client-side programming. Because JavaScript is executed when the page is served to the client, the user cannot interact with the server very much after the page is served unless further trips are made to the server. Furthermore, once a component is sent to the server, it is not necessarily executed and returned immediately. The server may have to perform other actions first. For instance, the Session Management Service of server-side JavaScript dictates when objects go in and out of scope. The predefined scoping objects are request, client, project, and server. For more information on object scoping see, Writing Server-Side JavaScript Applications.
With server-side components, the processing takes place primarily on the server. Here is the user scenario: A user clicks a URL to link to your application, and an HTTP request with that URL location is sent to the server. The server finds the page and starts to interpret the actions required by the page, starting at the top. When a <SERVER> tag is encountered, server-side JavaScript code runs and is interpreted by the server. If the server-side JavaScript code includes a call to a server-side Java component, the Java code runs on the server as well. If there are calls to a database, Enterprise Server communicates with the database through the LiveWire Database Service.
An example of a server-side JavaScript component in VJS is Server Send Mail. It is invisible in the UI, simply sending a mail message. You need to connect Server Send Mail to a UI component, such as a Submit button, so that the user can trigger Server Send Mail. Figure 2.2 shows how Server Send Mail works during runtime execution.
Figure 2.2 Server Send Mail
as it executes
In this scenario, mail is sent programmatically,
rather than directly by the user. You might need to send mail programmatically
if some of your users do not have email or if you wish to send mail from
a centralized location. This scenario assumes that the page has already
been loaded from a server and details only the events related to the Server
Send Mail component, which was triggered by the Submit button on the form.
A real form would undoubtedly contain other components, such as a text
field containing the message.
1. User submits a form by clicking a Submit button.
You connect the Server Send Mail component to the Submit button at design time.
2. Communicator submits form.
When the user clicks the Submit button, a request for the URL specified by the form's ACTION attribute is sent to the server.
3. Server-side JavaScript runs Server Send Mail object and gets data from submitted form.
The Enterprise Server instantiates the Server Send Mail object and prepares the message.
4. Enterprise Server sends message to Messaging Server.
5. Server locates email address in database.
The Messaging Server creates the mail message.
6. Server sends message to email address.
The Messaging Server sends the mail off to the addressee.
<SERVER>
write ("<SCRIPT> //do something in client-side JavaScript. </SCRIPT>")
</SERVER>In general, it is more efficient to use external JavaScript files than to embed <SCRIPT> tags. That way, the client-side JavaScript is sent to the client only once. Here is an example:
<SERVER>
write ("<SCRIPT> SRC='clientStuff.js' </SCRIPT>")
</SERVER>Such a component would consist of two files, one with a .jsb extension and one with a .js extension.
There are two components in VJS that can execute on both the client-side as well as the server-side: JavaScript Client Cursor and Java Client Cursor. Because they are both database cursor components, they each contain a set of rows that hold the data in a cache, with a pointer to the current row. However, the Java cursor fully supports the table and row interfaces, whereas the JavaScript cursor supports only the row interface. They both retrieve data from a database and send it to the client, where more logic is executed.
Both of these cursors are invisible to the end user and require a UI component to display their data. Each gets a result set from a database server and caches it on the client, minimizing trips to the server. The user can browse through the UI displaying the data, but when a query is generated, another trip to the database server is initiated to update the data. When the update occurs, Java Client Cursor refreshes only the UI element, whereas JavaScript Client Cursor refreshes the entire HTML page. It is best to use a Java Client Cursor with other Java components, but you might use JavaScript Client Cursor if Java is not supported in your end users' browsers.
Figure 2.3 shows JavaScript Client Cursor during runtime execution.
Figure 2.3 JavaScript Client
Cursor as it executes
In this scenario, the client requests a page containing
the JavaScript Buffered Cursor, then server-side JavaScript instantiates
a LiveWire cursor, retrieves data from the database, and streams the data
into client-side JavaScript. The client-side JavaScript is then sent back
to the client, along with the HTML page. Communicator then runs the client-side
JavaScript, instantiating JavaScript Client Cursor and allowing the user
to navigate through the data without requiring a trip to the server. However,
if the user wants to insert, update, or delete data, another trip to the
server is required. This scenario details only the events related to JavaScript
Client Cursor, not the other components on the page.
1. User clicks on a link to another page, which has a JavaScript Client Cursor on it.
The URL of the new page is either entered in the Location field of Communicator or linked to from the first page.
2. Communicator sends URL to server.
The new page is located by Enterprise Server.
3. Server-side JavaScript instantiates JavaScript Client Cursor and sends query to database.
4. Database executes query and produces result set.
5. Database sends result set to server.
6. Server-side JavaScript generates client-side JavaScript containing the client cursor and the data.
7. Server sends HTML and client-side JavaScript to client.
8. Communicator runs client-side JavaScript to instantiate the client part of JavaScript Client Cursor.
When the page is loaded for the first time, the data is already present. With each new query, the entire page is refreshed and the data is updated.Figure 2.4 shows Java Client Cursor during runtime execution. This example assumes that an SQL database is used and that the Coffee Table component is the UI element that displays the data.
Figure 2.4 Java Client Cursor
as it executes
In this scenario, the new page that is loaded
is not populated with any data from the database server. The user must
trigger Java Client Cursor on the page to retrieve the data. In this example,
the user does this by clicking the Get data button. The result set is then
retrieved from the database server and cached on the client. Java Client
Cursor executes on the client after the page has been returned by the server
and allows the user to navigate through the data without requiring a trip
to the server. Any changes or other queries the user generates do result
in a trip to the server. However, unlike JavaScript Client Cursor, Java
Client Cursor refreshes only the UI element displaying the data, not the
entire page. This scenario assumes the page has already been loaded from
a web server and details only the events related to Java Client Cursor,
not the other components on the page.
1. User clicks Get data button.
The Get data button is connected to Java Client Cursor, which the user cannot see.
2. Java Client Cursor sends SQL query to server.
3. Server-side JavaScript processes SQL query.
Server-side JavaScript instantiates the server-side portion of Java Client Cursor to process the SQL query.
4. Server-side JavaScript sends SQL query to database.
5. Database runs SQL query and produces result set.
6. Database returns result set to server.
7. Server-side JavaScript processes result set and sends to client.
The server-side portion of Java Client Cursor receives the results and forwards them to the client-side portion.
8. Java Client Cursor receives results and notifies Coffee Table.
The client-side portion of Java Client Cursor receives the results from the server and notifies Coffee Table that it has been updated.
9. Coffee Table displays data.
Coffee Table has been connected to Java Client Cursor as a "listener," meaning that it is updated whenever Java Client Cursor is updated. Any other components connected to Java Client Cursor as listeners would be updated simultaneously. With each new query, only the listening components are updated, not the entire page.
An example of a component that can execute on either the client or the server is an LDAP component, such as LDAPGetProperty. It is a JavaBean that uses LDAP to look up the value of a single property of a Directory entry. LDAPGetProperty requires the presence in the execution environment of the Java LDAP classes. These classes are included in Communicator, but you must add them to your server if you want the LDAP component to run on the server.
Figure 2.5 shows an LDAP component designed to run on the client.
Figure 2.5 LDAP component
used on the client
In this scenario, the LDAP component executes
on the client, communicating directly with LDAP on the Directory Server.
The LDAP component is invisible and is connected to the Get email button,
which triggers it, and the email address text field, where the address
is displayed. This scenario assumes that the page has already been loaded
from a web server and details only the events related to the LDAP component.
1. User types in a name and clicks Get email button.
The Get email button is connected to an LDAP component, which the user cannot see.
2. Connected LDAP component sends query to LDAP Directory Server.
The LDAP component communicates directly with the LDAP Directory Server in native LDAP.
3. LDAP Directory Server receives query and finds the email address.
4. LDAP Directory Server sends email address to client.
5. LDAP component receives email address.
6. Text field holding email address is updated.
The email address is updated in the text field. Any other components connected as listeners to this LDAP component will also be updated.Figure 2.6 shows an LDAP component that has been designed to run on the server.
Figure 2.6 LDAP component
used on the server
In this scenario, the LDAP component executes
on the Enterprise Server, communicating through it with LDAP on the Directory
Server. This scenario details only the events related to the LDAP component.
1. User clicks on a link to another page, which that has a server-side LDAP component on it.
2. Communicator sends URL to server.
3. Server-side JavaScript instantiates the LDAP component.
The LDAP component is instantiated on Enterprise Server in this example.
4. The LDAP component queries the LDAP Directory Server.
The LDAP component on Enterprise Server communicates directly with the LDAP Directory Server in native LDAP.
5. LDAP Directory Server receives query.
6. LDAP Directory Server returns result to server.
The Enterprise Server receives the results from the LDAP Directory Server.
7. Server-side JavaScript receives result and generates HTML to display it.
The Enterprise Server receives the results from the LDAP Directory Server and processes them in the server-side JavaScript execution environment.
8. Server sends generated HTML page to client.
9. Communicator displays the new page.
The new page contains the results of the query.