The View

Bishop uses WebMacro as a template engine. Without WebMacro Bishop would not be able to send views back to the browser.

WebMacro

WebMacro solves the problem with how to present the result from the model interaction to the client quite elegant. The dynamic html page that is generated from WebMacro is based on a template. In a WebMacro based application the variables that should be used during the evaluation are put in a Hashtable called the context. The developer is responsible for the context (ie s/he must put the needed variables in the hashtable manually).
The drawback with this is that the context has to be accessible to all objects that need to present anything to the user.

WebMacro does however do a great job transforming the template and the context (once it is properly setuped) into a html page. WebMacro is not limited to only generate html documents, it support any format. If for example, the template is a wml document the resulting page is in wml. It is this functionallity from WebMacro that is used by Bishop.

More information about WebMacro can be found here.

Bishop views

Consider a portal that provides the user with the possiblity to interact with serveral services at the same time. For example, the browser window is divided into two areas (not frames) each showing the current state of it's respective service/application. The applications you are running are an email client that shows your inbox and a news ticker that reterives new headlines once every hour. The email client check the inbox for new mail every fifth minute. Both applications could also be refreshed by the user clicking on a refresh button somewhere in the gui.

The problem is that when the inbox is refreshed (either by the user or automagically) we don't want to interact with the news ticker application. For example, if we have a portal with many services (>5) available on the same view and these services interact with databases or other tasks that takes long time to execute. The user doesn't want to wait for the other services to complete when s/he is only interested in the result of one.

A document genereated by Bishop is based on a view and subviews as shown in the figure.

The view and subviews are indepentent of each other. It is possible to add any subview to any view. The only restriction is that the combined html (/wml/xml/etc) of the views must result in a valid document, otherwise wont the browser be able show it to the user. When a user submits a request to any of the current displayed applications, only the view of the selected application is refreshed.

Bishop keeps the state of the client's view between requests. This makes it possible to only change a subview and/or add a new subview to the current view or to replace the current view with a new.

Each view and subview is associated with a template that is used by WebMacro during the page generation phase. The each view/subview can have 1 template. A template can be associated with 0 or more views/subviews.

The following Bishop script code shows how the view in the figure is constructed.

<bishop>
  <view template="portal.wm">
  <view name="emailClient" template="inbox.wm">
  <view name="newsTicker" template="news.wm">
</bishop>

The html and WebMacro code for the template portal.wm:

<html>
<head>
  <title>my portal</title>
</head>
<body>
  <p>
  #parse "$emailClient"
  </p>
  <p>
  #parse "$newsTicker"
  </p>
</body>
</html>

The #parse directive is a WebMacro command which evaluates a template and inserts it in the orginal temlate. In this case the templates named inbox.wm (the value of the variable $emailClient) and news.wm (the value of $newsTicker) are evaluated and inserted into portal.wm.

If the user now clicks the "new email" button in the mail client, the following bishop request is executed:

<bishop>
  <!-- model interaction goes here... -->
  <view name="emailClient" template="newEmail.wm">
</bishop>

This will cause the template associated with emailClient to be set to "newEmail.wm", while the view and newsTicker subview is unmodified.

The current view always keeps a list of it's subviews. When a new view is set using:

<bishop>
  <view template="aNewView.wm">
</bishop>

The view's list of subviews is cleared.