cool stuff
/src_docs/architecture/comp/overview.html, v125

Defining Client Capabilities

The purpose of this document is to explain how Barracuda determines Client Capabilities.

The Basics

First of all, all of Barracuda's Client Capabilities code is located in the org.barracudamvc.core.view package. It consists of several key objects:

  1. ViewCapabilities - when an object needs to render itself, it is passed a reference to the ViewCapabilities. This object defines the client capabilities and locale preferences. Specifically, it contains 4 distinct pieces of information:

    • FormatType
    • ClientType
    • ScriptingType
    • Locale - this represents the requested client locale
  2. FormatType - this defines the type of format the client expects (HTML, WML, XML, etc)

  3. ClientType - this defines the actual type of client (ie. browser version, etc).

  4. ScriptingType - this would define client scripting capabilities (JavaScript, VBScript, etc)

  5. ViewUtil - this is a utility class that can determine a client's view capabilities settings by examing a ServletRequest.

If you look at the UML diagrams for both the component the event models, you will observe that each provides access to the underlying ViewCapabilities--the event model through EventContext, and the component model through ViewContext. This information is determined from the HTTPRequest (note, however, that the capabilities information is not actually parsed/populated until it is requested; this is for performance reasons).

The basic idea is that when generating an HTTP Response to send to the client, the rendering agent--whether Barracuda components or custom event handing code--often needs to know something about the client capabilities in order to properly render a client view. The component model in particular depends heavily on this mechanism.

At this point, it may be helpful to identify the supported types for each object:

Format Type

Here are the basic Format Types:

It's important to note that we define these types using interfaces which actually extend from the base GenericData interface. What this means is that every type is an instance of all its parent types. This is very powerfule in that it allows us to write code like this:

ViewCapabilities vc = context.getViewCapabilities();
if (vc.getFormatType() instanceof FormatType.Html3x) {
   ...do something special...
}

The key advantage of this is that our code will get executed for both HTML 3.x and HTML 4.x clients. If a new version of HTML comes out that is backwards compatible, we can define it so that it extends Html4x and our code will continue to run.

We should also note that one of the key advantages of using interfaces is that they allow for multiple inheritance (unlike implementations). This is particularly important for the standards that are converging: in the case of XHTML, XHTML Basic will be a subset of XHTML Standard, thus XhtmlStandard1x must not only extend XhtmlStandard, but must also extend XhtmlBasic1x as well. It would be impossible to define this kind of relationship without using interfaces.

Of course, if all we have defined is interfaces, you might well be wondering: how do we ever get a reference to an actual concrete implementation? To solve this we defined a series of constants which are implemented as inner classes and implement the various FormatType interfaces. These include:

Each of these represents a specific implementation, which the ViewUtil class will select when parsing an HttpRequest, or which you can set programatically. As you may note, we have not yet defined any concrete values for the basic binary types. These will be created later if/when we actually have a need for them.

ClientType

ClientType works in a very similar fashion. We define both a series of basic interfaces:

as well as a set of convenient constants to reference concrete implementations:

ScriptingType

As expected, ScriptingType also works in a very similar fashion. We define both a series of basic interfaces:

as well as a set of convenient constants to reference concrete implementations:

To understand how all these actually get assigned based on an actual HttpRequest, please refer to org.barracudamvc.core.view.ViewUtil

 

 


Last Modified: 2006-01-02 15:59:13 -0500 (Mon, 02 Jan 2006)