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 Microsoft® 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 is 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 rich new environment. WFC is an object-oriented framework that encapsulates, simplifies, and unifies the Microsoft® Win32® and Dynamic HTML programming models. WFC is specifically aimed at developers that want to take full advantage of the spectrum of features essential to capitalize on both Windows and the Internet and therefore create winning solutions while cutting development time.

Developers want to create and deploy:

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, strong component model that emphasizes a relatively small set of very consistent, easy to understand rules about how components are created, how they interact, how to extend them and how to use and reuse them.

This base-line architecture was then applied across the key features of the platform to form a
uniform programming model for:

What follows 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 that there are different tools and runtimes 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 following two code snippets:

Win32-based UI

import com.ms.wfc.ui.*;
{
    Form   form1   = new Form();
    Button button1 = new Button();
    button1.setText("OK");
    button1.setPosition( 10, 10 );
    form1.add(button1);
}

Dynamic HTML-based UI

import com.ms.wfc.html.*;
{
    DhForm  form1   = new DhForm();
    DhButton button1 = new DhButton();
    button1.setText("OK");
    button1.setPosition( 10, 10 );
    form1.add(button1);
}

While both generate interactive user interface, the code on the left creates UI that is built directly on top of Win32's USER/GDI implementations while the code on the right generates HTML compliant with the Worldwide Web Consortium (W3C) This link takes you to a site outside of microsoft.com specification. What should be obvious is that the programming model is the same for both cases. In both there are components with empty constructors, properties and methods that are the same and are addressed the same way.

What is not obvious in the two code snippets above is that while both will execute on the client, the code on the right can also execute on a server, sending the result of the generated HTML to an unknown client. (More on this below.)

WFC also takes full advantage of J/Direct This link takes you to a site on microsoft.com 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 before.

Win32-based IO

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);
}

Dynamic HTML-based UI

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);
}

Note how the code to create a bitmap on the Win32 client on the left is the exact same code that runs on the Web server on the left. 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.

To take full advantage of Microsoft® Internet Explorer 4.0, developers using WFC can very easily and intuitively 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 have Win32 dialogs that come up over the browser and have all of those seamlessly communicate with the intrinsic HTML on the page.

import com.ms.wfc.ui.*;
import com.ms.wfc.html.*;

{
  // Bind to a text span called "text1" 
  // in the HTML document:

  DhText t = new DhText();

  setBoundElements( new DhElement[] { 
                  t.setBindID("text1") } );

  // Hook it's 'onclick'

  t.addOnClickHanlder( 
           new EventHandler(this.onText1Click) );
}

public void onText1Click(Object s, Event e )
{
  // In response to click on text span, 
  // show a Win32 dialog on top of the browser

  Form1 form1 = new Form1();
  form1.showDialog();
}

Client/Server Unification

With the advent of Dynamic HTML (DHTML) This link takes you to a site outside of microsoft.com and Microsoft Internet Explorer (MSIE) 4.0's This link takes you to a site on microsoft.com implementation of that specification, developers have much more flexibility. When targeting Microsoft Internet Explorer 4.0 on the client, many of the decisions about when and where code has to 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 the Component Object Model (COM) This link takes you to a site on microsoft.com on Internet Information Server (IIS) This link takes you to a site on microsoft.com as well as Microsoft Internet Explorer. This means developers using WFC can write a single module of that will run "behind" either an Active Server Page or an HTML page running in Microsoft Internet Explorer 4.0 with simple runtime checks to validate which host they are running behind in case they need to know.

Common Event Model

Another important way WFC leverages Microsoft Internet Explorer is in event handling. By unifying the programming model for handling and firing events, developers that target Microsoft Internet Explorer's Win32 browser can apply the same code to both Win32 based UI as well as HTML:

Win32-based UI

import com.ms.wfc.ui.*;

{
   // This watches for WM_LBUTTONDOWN

   button1.addOnClick(
    new EventHandler(this.onClick));
}

public void onClick(Object s, Event e )
{
}

Dynamic HTML-based UI

import com.ms.wfc.html.*;

{
   // this watches for <INPUT ONCLICK=

   button1.addOnClick(
    new EventHandler(this.onClick));
}

public void onClick(Object s, Event e )
{
}

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 Microsoft® JScript® and Microsoft® Visual Basic® Scripting Edition (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 code snippets above.

Cross Discipline Productivity

Currently developers providing real world client/server solutions need to master at least three coding disciplines just to display user interface:

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 (for example, Microsoft Front Page This link takes you to a site on microsoft.com). Microsoft also recommends that the HTML elements that are to be addressed at runtime by WFC be marked as such using attributes. This makes it much faster to hook UI events to the elements at the client or do dynamic element substitution on the server.

Single Data-Binding Mechanism

At the core of data binding in WFC is the Microsoft Universal Data Access This link takes you to a site on microsoft.com initiative. This is very 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 (for example, "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 details form can be bound to the exact same data source such that as records are navigated in the grid are reflected in the HTML. For clients that do not have Microsoft Internet Explorer or WFC installed, this same application, largely unchanged can be deployed and run from a server.

WFC make 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 it's robust component architecture and the fact that it is an open well-defined class library that makes WFC's approach much more amenable to professional developers.

Summary

There are many topics to cover and much more detail that can and will follow, but for now it should be clear what the mission of WFC is:

To be 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 as well as Internet standards such as HTML and HTTP.

© 1999 Microsoft Corporation. All rights reserved. Terms of use.