By Victor Stone
Unifying the Programming Model for Windows and the Internet
Every day, more organizations are turning to client/server solutions based on Internet protocols running on the Windows platform. As developers, we've all been finding our way around this new application architecture, often frantically searching for ways to more easily bridge the assorted technologies. It's easy to get excited about the new development opportunities fostered by the marriage of the Internet and client/server computing. However, when implementing solutions across these different programming disciplines (with varying degrees of maturity), it's just as easy to get frustrated while productivity suffers.
In response, Microsoft is creating the Windows Foundation Classes (WFC) to lower the bar of entry for developers into this new environment. WFC is an object-oriented framework that encapsulates, simplifies, and unifies the Win32 and Dynamic HTML programming models. WFC is specifically aimed at developers who want to take full advantage of the spectrum of features essential to capitalize on Windows and the Internet to create winning solutions while cutting development time.
Developers want to create and deploy:
applications that adhere to industry and worldwide standards for networking, data sharing, and user interface that allow their software to interact with software from any vendor.
Web server applications that respond to HTTP URL requests, and, in turn, provide database connectivity. These applications return HTML visible by standards-based Web browsers on platforms ranging from Windows CE, to WebTV, to the Macintosh and legacy 16-bit Windows.
specialized business components that transact a specific line of business on high-volume servers.
client front-ends that take full advantage of the richness of the latest DHTML features, including rich encapsulations of commonly used controls, e.g. trees, calendars, grids, etc.
applications triggered from server events that create and maintain static Web sites.
secure, robust applications that are easy and inexpensive to create, deploy, and administer.
high-performance, complex, feature-rich client front-ends that invoke specialized DCOM objects via high-bandwidth protocols.
applications with clients that behave just as well offline as when connected, and that reconcile data changes upon reconnection.
applications that bind to local and/or remote heterogeneous data formats.
systems that feature some combination, or all, of the above.
With WFC, developers can now build these applications without sacrificing the productivity they have come to expect from traditional class libraries and tools.
Common Component Model
WFC accomplishes this by boiling everything down to a common component model that emphasizes a relatively small set of consistent rules about how components are created, how they interact, how to extend them, and how to use and re-use them.
This base-line architecture was then applied across the key features of the platform to form a
uniform programming model for:
a user interface based on DHTML and Win32.
operations performed on the server, or for clients with high- or low-speed connections, or disconnected clients.
operating from the MS-DOS command line.
data binding to SQL, Access, Oracle, XML, or tabular data — local or remote.
The following is an exploration of what developers can expect to find when targeting WFC in their client/server solutions.
Common UI Programming Model for DHTML and Win32
The creators of WFC understand there are different tools and run times that are applicable for different situations. However, they also believe that developers are more productive if they can learn one set of coding principles and practices and apply it while targeting different cases.
Take the code fragments in Figure 1 and Figure 2 for example. While both generate an interactive user interface, the code in Figure 1 creates a UI that is built directly on top of Win32's USER/GDI implementations, while the code in Figure 2 generates HTML code that is compliant with the World Wide Web Consortium (W3C) specification.
import wfc.ui.*;
{
Form form1 = new Form();
Button button1 = new Button();
button1.setText("OK");
button1.setPosition( 10, 10 );
form1.add(button1);
}
Figure 1: Creates a UI built directly on Win32's USER/GDI implementations.
import wfc.html.*;
{
DhPanel form1 = new DhPanel();
DhButton button1 = new DhButton();
button1.setText("OK");
button1.setPosition( 10, 10 );
form1.add(button1);
}
Figure 2: Generates HTML compliant with the World Wide Web Consortium specification.
Obviously, the programming model is the same for both. In both, there are components with empty constructors, properties and methods that are the same — and that are addressed the same way. What's not so obvious is that while both will execute on the client, the code in Figure 2 can also execute on a server, sending the result of the generated HTML to an unknown client.
WFC also takes full advantage of J/Direct technology and makes it possible for developers to write against the WFC Graphics objects on the server for Web applications, or on Win32 client machines. Taking advantage of the latter results in graphic rendering and reaction times the likes of which Java programmers have never seen.
Note how the code to create a bitmap on the Win32 client in Figure 3 is the same code that runs on the Web server in Figure 4. The only difference, again, is where the image is rendered — immediately to the screen in the case of the client, or sent to the client's HTML browser.
Bitmap bitmap;
{
bitmap = new Bitmap(100,50);
Graphics g = bitmap.getGraphics();
Font f = new Font("Haettenschweiler",12);
g.setFont(f);
g.drawString("Cool!");
}
public void onPaint(PaintEvent pe) {
// CLIENT:
// Write the image to the screen:
pe.graphics.drawImage(bitmap);
}
Figure 3: The code to create a bitmap on the Win32 client.
Bitmap bitmap;
{
bitmap = new Bitmap(100,50);
Graphics g = bitmap.getGraphics();
Font f = new Font("Haettenschweiler",12);
g.setFont(f);
g.drawString("Cool!");
}
public void initForm() {
// SERVER:
// Send the image to the client:
String fname = "cool.bmp";
File f = new File();
f.create(fname);
bitmap.save(f);
f.close();
DhImage img1 = new DhImage(fname);
getResponse().write(img1);
}
Figure 4: The code that runs on the Web server.
To take full advantage of Microsoft Internet Explorer 4.0, developers using WFC can easily mix and match Win32, COM, and HTML components all in the same UI and coding namespace. With only a few lines of code, developers can put WFC-authored Win32/COM controls directly into the HTML page. It is just as easy to display Win32 dialog boxes over the browser and have all of them communicate seamlessly with the intrinsic HTML on the page (see Figure 5).
import wfc.ui.*;
import wfc.html.*;
{
// Find a text span called "text1" in the HTML document.
DhText t = getDocument().findElement("text1");
// Hook its OnClick event.
t.addOnClickHanlder(
new DhEventHandler(this.onText1Click));
}
public void onText1Click(Object s, DhEvent e) {
// Display a Win32 dialog box in response to a click
// on a text span.
Form1 form1 = new Form1();
form1.showDialog();
}
Figure 5: Displaying a Win32 dialog box over a browser.
Client/Server Unification
With the advent of Dynamic HTML (DHTML) and Internet Explorer 4.0's implementation of that specification, developers have much more flexibility. When targeting Internet Explorer 4.0 on the client, many of the decisions about when and where code must run, become more about where the code should run to build the best solution.
Part of the way WFC accomplishes this symmetry is by leveraging COM on Internet Information Server (IIS) as well as in Internet Explorer. This means developers using WFC can write a single module that will run "behind" either an Active Server Page or an HTML page running in Internet Explorer 4.0 with simple run-time checks to validate which host they are running behind (in case they need to know).
Common Event Model
Another important way WFC leverages Internet Explorer is in event handling. By unifying the programming model for handling and firing events, developers that target Internet Explorer's Win32 browser can apply the same code to a Win32-based UI (see Figure 6) as well as HTML (see Figure 7).
import wfc.ui.*;
{
// This watches for WM_LBUTTONDOWN.
button1.addOnClick(new EventHandler(this.onClick));
}
public void onClick(Object s, Event e) {
}
Figure 6: The code applied for a Win32-based UI.
import wfc.html.*;
{
// This watches for <INPUT ONCLICK=
button1.addOnClick(new DhEventHandler(this.onClick));
}
public void onClick(Object s, Event e) {
}Figure 7: The code applied for
Event handlers can be mixed and matched at will, including pointing events coming from DHTML and Win32 at the same listener (n to 1), or having multiple listeners to a single event source embedded anywhere in the UI (1 to n). Borrowing a page from JScript and VBScript, the WFC event model is not interface-based; it is method-based. That means any code, in any class, becomes a listener simply by implementing a method with the proper argument signature and letting the source know they want to listen in — as evidenced by the previous code fragments.
Cross-Discipline Productivity
Developers providing real-world client/server solutions currently need to master at least three coding disciplines just to display a user interface:
Typography (HTML, CSS, etc.)
Scripting (JavaScript, VBScript, or both, DHTML, DOM, etc.)
Graphics/Controls Libraries (AWT, JFC, etc.)
WFC eliminates the need to repatriate professional, code-writing developers into foreign disciplines not directly related to the types of solutions they are commissioned to create and maintain.
While it is very easy to create great-looking HTML content by writing code with WFC, Microsoft encourages developers to pre-author HTML in a Web-authoring tool. Microsoft also recommends that the HTML elements that are to be addressed at run time by WFC, be marked as such using attributes. This makes it much faster to hook UI events to the elements at the client, or to do dynamic element substitution on the server.
Single Data-Binding Mechanism
At the core of WFC data binding is the Microsoft Universal Data Access initiative. This is rich and far-reaching architecture that gets developers access to most of the world's data. At the programming level, however, WFC encapsulates the complexity while retaining all the functionality of the underlying data system.
With just a few lines of code, a WFC Grid control and an HTML single record details form (e.g. "First Name," "Last Name," etc.) can be placed on the same HTML page. With a few more lines of code, both the master and the detail form can be bound to the same data source so that records navigated in the grid are reflected in the HTML. For clients that don't have Internet Explorer or WFC installed, this same application, largely unchanged, can be deployed and run from a server.
WFC makes this possible by abstracting the data-binding programming model for client and server user interface and being intelligent about when to apply client-side data binding vs. server-side data binding. While other tools attempt similar functionality, it is its robust component architecture and the fact that it is an open, well-defined class library that makes WFC's approach more amenable to professional developers.
Conclusion
There are many topics to cover and much more detail that can and will follow, but for now the mission of WFC should be clear: WFC is a framework for quickly writing and maintaining robust client/server applications on Windows using open Internet standards. To accomplish this, WFC introduces a compelling component model that is the basis for a unified programming model for classic Win32-based programming, and Internet standards, such as HTML and HTTP.
Note: The code fragments in this article are based on a very early pre-release of WFC and are therefore subject to change before the final release. They are included as illustrative of the kinds of things that will be possible with the final release of WFC, not the exact naming of objects or syntax for access to those objects.
Victor Stone is currently "Technical Catalyst" in the RAD tools group at Microsoft. He has been working on marrying Web and COM technologies for Visual J++, Visual Basic, Internet Explorer, Java VM, Scripting Engines, and Interactive TV. His latest projects are the HTML package in WFC and guarding the water cooler. Before coming to Microsoft, he worked at Inprise (nee Borland), Peter Norton Computing, Magna Typesetting Software, and more than a few loading docks. He has no formal education past the 11th grade.