The wfc.html package can also be used on the server to provide a programmatic model for generating HTML and sending it to the client page. Although it is created using the dynamic HTML package, this model is actually static because the server Java class has no interaction with the client document. Instead, the server composes HTML elements and sends them off sequentially to the client. While relatively static in terms of an associated client document, the power of dynamic HTML is still evident on the server. For example, you can apply DhStyle attributes to all parts of some template HTML code and then generate vastly different looking pages by just changing the DhStyle attributes, rather than having to programmatically generate all the individual style changes. Another advantage comes from the fact that you can use the same model for generating dynamic HTML for both client and server applications, thereby making the HTML generation easier to learn and remember.
There are currently two modes of generating HTML on the server. Both use Active Server Pages (ASP) scripting and a class based on the wfc.html classes. The first is the "bare-bones" approach that relies more on the ASP script and does not require registering the class file. The uses registration and is much closer to the model that you use on the client because it places more control inside the class than in the script.
This method uses two ASP methods on the server page: getObject() and Response.Write(). The getObject() method is used to instantiate a class based on the WFC wfc.html classes; the Response.Write() method writes the generated HTML string to the client. The wfc.html.DhElement class provides a generateHTML() method that creates the HTML string; this string is then sent to the client page using the ASP Response.Write() method.
For example, say you have a class called MyServer that extends DhSection and incorporates some HTML elements. In your ASP script, you would call getObject("java:MyServer") to create a DHTML object. You can then perform whatever actions you want on the object (for example, setting properties) from your ASP script. When you have finished, you would call the object's generateHTML() method to generate the string and pass that result to the ASP Response.Write()method to send the HTML to the client. The following code fragments show the relevant ASP script and Java code for creating a DhEdit control in HTML and sending it to the client.
ASP SCRIPT
Dim f,x
set f = getObject( "java:dhFactory" )
set x= f.createEdit
x.setText( "I'm an edit!" )
Response.Write( x.generateHTML() )
Response.Write( f.createBreak().generateHTML() )
.
.
.
JAVA CODE
public class dhFactory implements DhColors, DhUnits{
public dhFactory(){ }
public DhBreak createBreak() {
return new DhBreak(); }
public DhEdit createEdit(){
return new DhEdit(); }
.
.
.
}This registered method is slightly more sophisticated and closer to client model. In this method you follow these steps:
Javareg /register /class:myClass /prodid:MyClassAt run time, the framework recognizes that your wfc.html-based class is running on a server and acts accordingly.
Once instantiated, all the sending of HTML is performed when you call the DhModule.write() method in your derived class. The write() method in a server class is similar to the add() method in a client class; however, instead of adding the element to the document, it is sent to the client in a serial stream (in fact, if write() is called from a client class, add() is automatically called).
[NEED SAMPLE CODE HERE] Besides using the write() method instead of the add() method, there are very few other differences between the interpretation of server and client HTML classes. One important difference, however, is that in a server class, elements, once written (sent to the client), cannot be modified afterwards as they can be on a client document. For example, the DhCantModifyElement exception, which is relevant only for server applications, is thrown after a write() has been performed on an element if an attempt is made to modify that element again. This underscores the fact that there is no real interoperation between the server Java class and the client document as there is on the client between the Java class and the document: from the server's standpoint, once written, the element is essentially gone.
Finally, it should be pointed out that the wfc.html package is still in development and there are features of server Java programming that are still to come. The most important of these is the implementation of a template model of server programming which will allow you to provide an HTML template embedded with attributes that are recognized by wfc.html classes. The server class can then parse the HTML, pull out the HTML that is appropriately tagged, compose it, and send it to the client.