The purpose of this document is to explain how
Barracuda determines Client Capabilities. First of all, all of Barracuda's Client
Capabilities code is located in the org.enhydra.barracuda.core.view
package. It consists of several key objects:
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 - this defines the type of format the
client expects (HTML, WML, XML, etc)
ClientType - this defines the actual type of
client (ie. browser version, etc).
ScriptingType - this would define client
scripting capabilities (JavaScript, VBScript, etc)
- 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:
- GenericData
- AsciiData
- Html
- Xml
- Xml1x
- Vxml
- Wml
- Xhtml
- XhtmlBasic
- XhtmlBasic1x
- XhtmlStandard
- BinaryData
- Unknown
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:
- FormatType.HTML_3_0
- FormatType.HTML_3_1
- FormatType.HTML_3_2
- FormatType.HTML_4_0
- FormatType.HTML_4_1
- FormatType.CHTML_1_0
- FormatType.CHTML_2_0
- FormatType.XML_1_0
- FormatType.VXML_1_0
- FormatType.XHTML_BASIC_1_0
- FormatType.XHTML_STANDARD_1_0
- FormatType.UNKNOWN_FORMAT
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:
- GenericBrowser
- HtmlBrowser
- HtmlStandardBrowser
- Html32Browser
- Html40Browser
- ChtmlBrowser
- XmlBrowser
- VxmlBrowser
- WmlBrowser
- XhtmlBrowser
- Unknown
as well as a set of convenient constants to reference concrete implementations:
- ClientType.HTML_BROWSER
- ClientType.HTML_3_2_BROWSER
- ClientType.IE_3x
- ClientType.IE_4x
- ClientType.NN_3x
- ClientType.NN_4x
- ClientType.OPERA_4x
- ClientType.HTML_4_0_BROWSER
- ClientType.IE_5x
- ClientType.IE_6x
- ClientType.NN_6x
- ClientType.OPERA_5x
- ClientType.CHTML_BROWSER
- ClientType.WML_BROWSER
- ClientType.XML_BROWSER
- ClientType.UNKNOWN_BROWSER
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:
- ScriptingType.JAVASCRIPT_1x
- ScriptingType.JAVASCRIPT_1_0
- ScriptingType.JAVASCRIPT_1_1
- ScriptingType.JAVASCRIPT_1_2
- ScriptingType.JAVASCRIPT_1_3
- ScriptingType.JAVASCRIPT_1_4
- ScriptingType.JAVASCRIPT_1_5
- ScriptingType.WMLSCRIPT_1x
- ScriptingType.WMLSCRIPT_1_0
- ScriptingType.WMLSCRIPT_1_1
- ScriptingType.WMLSCRIPT_1_2
- ScriptingType.NONE
To understand how all these actually get assigned based on an actual HttpRequest,
please refer to org.enhydra.barracuda.core.view.ViewUtil |