InterSystems Caché Technology Guide

Chapter Four:
Building Fast Web Apps Fast With Caché Server Pages

“Building fast Web apps fast” uses the word fast two times. That’s because it is possible to build sophisticated database-oriented Web applications with Caché Server Pages (CSP) more rapidly than with traditional approaches, and also because the built-in Caché database is the world’s fastest database, capable of running systems with tens of thousands of simultaneous users.

There are many ways to write Web applications with Caché – including all of the traditional ways that use SQL to access the database. In this chapter, we’re going to discuss another, more direct approach called CSP.

CSP is a technology that is provided as part of the Caché Application Server. It is the fastest way for Caché applications to interact with the Web, providing:

• An advanced object-oriented development approach.
• Ultra-high performance and scalability at run time.
• Component-based development with InterSystems Zen™.

CSP supports HTML, XML, and other Web-oriented mark-up languages.

CSP is not a Web design tool, although it can be used with them. While Web design tools often concentrate solely on the production of static HTML, CSP goes beyond the appearance of pages to aid in the development of application logic. It also provides the run time environment that enables rapid execution of code within the Caché Application Server.

CSP supports a strong procedural programming environment, so applications can be written with a level of sophistication and exactness that exceeds what is possible with pure application generation technologies. It also supports rapid development through its class architecture, which produces “building blocks” of code that can be combined, and through the use of wizards, which can quickly produce simple versions of customizable code. The result is the ability to quickly develop very sophisticated Web applications.

THE CACHÉ ADVANTAGE Object-oriented procedural programming, plus Caché wizards, results in rapid development of sophisticated browser-based database applications.

 

Some of the characteristics of CSP are:

• Dynamic Server Pages – Because pages are created dynamically on the application server by application code, rather than having a Web server simply return static HTML, applications can respond rapidly to a variety of different requests and tailor the resulting pages that get sent back to the browser.
• Session Model – All of the processing related to pages from a single browser are considered part of a session – from the first browser request until either the application is completed or a programmable timeout occurs.
• Server State Preservation – Within a session, application data on the server – and even the entire application context – can be automatically retained across browser requests, making it much easier to develop and run complex applications.
• Object Architecture – Because every page corresponds to a class, code and other characteristics common to many pages can be easily incorporated through inheritance. Data is also typically referenced through objects with all of the benefits of object-oriented programming.
• XML – XML provides a powerful alternative to HTML for building Web pages. CSP works the same way with XML as it does with HTML. Instead of the programmer supplying HTML in the Page() method, XML is provided.
• Caché Application Tags for Automatic Generation of Server Application Code – These extended HTML tags are as easy to use as traditional HTML tags. When added to an HTML document, they generate sophisticated application code providing a variety of functionality, such as opening objects, running queries, and controlling program flow. These tags are extensible – developers can create their own to suit their specific needs.
• Component-based Development – With Zen, developers can build pages using a component model that uses a rich suite of pre-built object components to increase the interactivity, visual sophistication, and consistency of the user interface.
• Integration with Popular Web Design Tools – CSP works with a variety of tools that make it easy to visually lay out a page. With Dreamweaver, CSP goes a step further with the ability to add Caché Application Tags through simple point-and-click interaction. CSP also includes a wizard that makes it easy to create forms that display or edit data in a Caché database. Server Methods Callable from the Browser – To facilitate development of more dynamic interactive applications, CSP makes it easy to invoke server-side methods. When an event occurs in the browser – typically because the user took some action – application code on the server can be invoked and a response to the event generated, all without the overhead of transmitting and displaying a whole new page.
• Encryption – Caché automatically encrypts data in the URL, to help authenticate requests and prevent tampering. The encryption key is kept only on the server, and it is only good for the life of the single session.

That's a lot of technology – but it does not have to be hard to use. We've focused on making CSP simple to use, with most of these capabilities working automatically for you. Our philosophy is power through simplicity – the complexity should be in our implementation, not in your programming.

THE CACHÉ SERVER PAGE MODEL

Traditional Web Technologies

With traditional Web technology, a request is sent to the Web server, and the Web server retrieves a sequential file of HTML that it sends back to the browser. When applications involve variable data, development gets more complicated, with programmers typically using CGI (with languages such as Perl or tcl) on the Web server and sending SQL queries and stored procedure requests to the database. As a programming environment, this leaves much to be desired, and execution – particularly with a large number of users – can be quite inefficient as the Web server gets heavily overloaded.

With CGI, each browser request typically creates a new process. To avoid this overhead, programmers sometimes link application code directly to the Web server, with the unfortunate side effect that an error in such code can crash the entire Web server.

Dynamic Server Pages

CSP uses a different programming and execution approach: Dynamic Server Page Technology. Content (HTML, XML, style sheets, images, and other types) is generated programmatically at run time on the Caché Application Server, rather than coming from sequential files, allowing much greater flexibility in responding to page requests.

Most of the application code executes on the Caché Application Server, which may or may not be on the same computer as the Web server. Some code – typically JavaScript or Java – may run on the browser, usually to support operations such as data validation, reformatting, or invoking server-side code.

With this approach, processes don't have to be created for each browser request (as they do with the traditional CGI approach), boosting performance. And since the application code isn’t linked to the Web server, an application error cannot crash the Web server.

Sessions – The Processing Model

All of the processing related to pages from a single browser are considered part of a session – from the first browser request until either the application is completed or a programmable timeout occurs. When the Web server receives a page request (URL) with the file extension “.csp”, that request is sent (by a thin layer of Caché code attached to the Web server) to the appropriate Caché Application Server, which may be on a different computer.

When the Caché Application Server receives the request, it determines whether a session is already in progress for that browser. If not, one is started automatically. Caché then executes application code associated with that particular page – performing the actions requested by the user and programmatically creating HTML, XML, image, or other content that is sent back to the browser.

A session ends when a property is set in the Session object terminating the session. Applications that run stateless may elect to terminate the session on each page.

State Preservation

One of the challenges facing developers is the inherently stateless nature of the Web – there’s usually no simple way to retain information on the server from one request to the next. Applications typically send all of the state information they need to retain out to the browser in URLs or hidden form fields. That's not an effective technique for more complex applications, which may resort to saving data temporarily in files or databases. Unfortunately, this imposes significant overhead on the server, and it makes programming considerably more difficult.

Caché’s session model enables Caché to automatically and efficiently preserve data between calls from a browser. CSP provides a Session object that contains general session information plus properties that enable the programmer to control various session characteristics. The application can store its own data in the Session object, which is automatically retained from one request to the next.

The application determines how much state to preserve by setting the Preserve property of the Session object to 0 or 1. (The default is 0, and it can be dynamically modified at run time.)

• 0 – Data stored in the Session object is retained. (Data is simply set into a multidimensional property that accepts data of any type and allows any number of subscripts – including string valued subscripts – without any declarations.)
• 1 – Caché dedicates a process to the session so that all of the state of the process is retained, including all variables (not just those in the Session object), I/O devices, and locks.

A setting of 0 allows a logical partitioning of all preserved data and permits multiple sessions to share a single process, but it preserves less state. A setting of 1 is easier for the programmer and provides a wider range of capabilities, at a cost of increased server resources.

The Request Object

CSP automatically provides several objects, in addition to the Session object, to help the programmer process the page. One of these is the Request object. When a page is received, the URL is decoded and its contents are placed into the Request object. The request object contains all name/value pairs and any form data, along with other useful information. For example, the value of the name “FilmID” could be obtained by the code:

%request.Data(”FilmID”,1)		// the 1 indicates we want the
		// 1st value for this name
		// in case multiple values are
		// present for this name

 

THE CACHÉ ADVANTAGE By automatically preserving state information on the server, there’s less network traffic and less overhead on the server, as the application doesn’t have to keep filing and accessing data on every page request. And programming the application is simpler. The use of Dynamic Server Pages and the Caché Application Server results in greater flexibility to respond to requests, faster execution without the risk of application errors bringing down the Web server, and a richer programming environment.

 

CLASS ARCHITECTURE OF WEB PAGES

For each Web page, there is a corresponding page class that contains methods (code) to generate the page contents. When a request is received, its URL is used to identify the corresponding page class, and the Page() method of that class is called. Usually page classes are derived from a standard Web page class “%CSP.Page” that provides every page with various built-in capabilities, such as the generation of headers and encryption. Those standard capabilities can be overridden through a variety of means – deriving from another superclass, using multiple inheritance, or simply overriding specific methods.

This class architecture makes it easy to change behavior for an entire application and to enforce a common style. It also brings all of the other programming advantages of object programming to Web development.

The page class contains code to perform the requested action and generate and send a response to the browser, but not all of the application code that is executed is in that page class. In fact, most of the executed code is typically in methods of various database classes and perhaps additional business logic classes. Thus, the development process consists of developing both page classes and database classes (plus perhaps additional business logic classes).

In general, we recommend that page classes contain only user interface logic. Business logic and database logic should be put into different classes, so that there is a clean separation of user interface code from the business and database logic, and it is easier to add additional user interfaces later.

MULTIPLE DEVELOPMENT STRATEGIES

A page class is created for each Web page and contains the code to be executed for that page. There are several ways to build page classes, and most applications use more than one:

• CSP File – An HTML file with embedded Caché Application Tags is written using a simple text editor or Web design tool. That sequential file (a “CSP file”) is not sent directly to the browser, it is compiled to generate a page class.
• Direct Programming – Programmers write the entire page class by coding the appropriate methods.
• Zen – Programmers write the page class using pre-built interactive object components

Simple pages are often quicker to develop with CSP files and wizards, but it may be easier to program more complex pages either directly or with Zen.

CSP FILES

CSP files are sequential HTML files with embedded Caché Application Tags that are compiled into page classes – the same sort of page classes that a programmer might write directly. Those page classes are then compiled to generate code that runs on the Caché Application Server in response to browser requests.

Caché Studio includes a Form Wizard that automatically generates a CSP file to edit or view a database class. The user simply clicks on the database class of interest and then clicks on the set of properties to be displayed. The Caché wizard does the rest – adding HTML and Caché Application Tags to the page. Since the wizard outputs HTML, if the result is not exactly what you want, it is easy to edit it.

The CSP file approach is powerful because:

• Web artists can design the visual layout while programmers concentrate on the code.
• Much of the user interface can be programmed non-procedurally in a visual environment and kept isolated from the business and database logic.
• It is often easier to customize an application for a particular user by allowing non-programmers to modify the visual presentation and add simple capabilities.

Since the visual specifications of the application are kept separate from most of the programming logic, it is relatively easy to change the appearance without reprogramming. Simply edit the HTML or XML file and recompile the page.

Although a complete simple application can be created this way, more commonly a programmer supplies additional code. This additional code is provided though application tags that either include the procedural code or invoke code in other classes. However, complex pages with a lot of procedural code are often easier to write using the direct programming approach rather than a CSP file.

Caché also includes an add-in for Dreamweaver, the popular Web page design tool. It provides point-and-click support for adding Caché Application Tags, as well as a Caché Form Wizard that automatically generates the code needed to view or edit a database object.

Caché Application Tags

Caché Application Tags can be added to CSP files. They are used just like standard HTML tags, but they are really instructions to the Caché Web Compiler to generate application code that provides a variety of functionality, such as accessing database objects, running queries, program flow control, and executing code on the Caché Application Server. Caché Application Tags are extensible – developers can create their own to suit their specific needs.

Caché Application Tags are not embedded in HTML that is sent to a browser – they are only in the CSP file read by the Caché Web Compiler. That compiler automatically transforms them into standard HTML, which can be processed by any browser.

HYPER-EVENTS

CSP hyper-events allow events occurring on a browser (such as mouse clicks, field value changes, or timeouts) to invoke server-side methods and to update the current page without repainting it. After taking the appropriate action, that server method can return code – typically JavaScript – for execution by the browser. Using hyper-events, Web applications can become more interactive and responsive.

Within a CSP page, a server side method is invoked simply with the syntax:

"#server(...)#"

For example, suppose that when the user clicks on a shopping cart image, we want to call a server method called AddToCart(). Then the HTML definition for the image might include:

onClick="#server(..AddToCart())#"

The Web compiler will replace this syntax with JavaScript code that when run on the browser, will invoke the Caché server method.

ZEN AND COMPONENT-BASED WEB PAGES

Zen provides a simple way to rapidly create complex, data-rich Web applications with a sophisticated visual appearance and highly interactive user interface. Zen is not a 4GL. Zen is a rich library of pre-built object components and development tools based on InterSystems’ CSP and object technology. Zen is especially appropriate for developing a Web version of client/server applications that were originally built with tools such as Visual Basic or PowerBuilder.

Zen components allow much more dynamic interactions – you’re not restricted to the “submit” mechanism to send values to the server. For example, with the Zen form component, you can define your own custom validation, including immediate calls to the server without requiring a page request and subsequent repainting. For users, this represents a more natural way to enter data.

Zen uses the session management mechanism of CSP, providing user authentication, data encryption, and the retention of persistent session data across page requests. All communication between the browser and server occurs by sending objects back and forth using a more sophisticated version of the technique often referred to as AJAX (Asynchronous JavaScript and XML).

Zen-based pages can be easily intermixed with pages developed using other CSP approaches to Web development.

What is a Zen Component?

A Zen component is a class definition that specifies the appearance and behavior of the component on the page. The Zen class definition contains, in a single document, the entire definition of a component, including the style sheets, server code, and client code.

At run time, Zen creates two objects for each component used in a page: a client-side object that Zen automatically creates as a JavaScript object within the browser, and a server-side object. Zen automatically manages the state of both objects and manages the flow of information between them.

Types of Zen Components

The Zen library includes components that implement all the standard HTML control types: input boxes, text boxes, buttons, check boxes, etc. These components have additional behaviors inherited from the Zen control class.

Zen also includes a set of more complex, data-rich components that automatically display data from the database and know how to dynamically update this data in response to user events. For example, Zen’s powerful table component automatically displays data within an HTML table using a database query. The table component supports paging, scrolling, sorting by columns, filtering, and a variety of styles. The contents of the table can be refreshed from the server without repainting the entire page.

Other Zen components include:

• Menu – A variety of menu types are supported.
• Grid – Add spreadsheet-style behavior to a Web page.
• Tree – Display hierarchical data with a tree control.
• Tab – A tab component contains a series of tabs, each of which contains a series of other components.
• Chart – A rich set of chart components are implemented using SVG, including line, area, bar, pie, hi-low, and XY charts.
• Graphical Meters – Speedometers, gauges, etc., let you display data as dynamic visual components.

Changing the Appearance of the Zen Library Components

All Zen components support a set of properties that control look and feel. Applications can set these properties at run time to change the values, appearance, and behavior of components.

The visual appearance is also controlled by Standard CSS (Cascading Style Sheet) style definitions. You can override these styles (to change fonts, colors, size, etc.) on an application wide, page-wide, or individual component basis.

You can create sub-classes of the Zen library components to further override appearance and behavior.

Creating New Zen Components

One of the main strengths of Zen is that it is easy to create new components.

Every component is implemented as a class. To create a new component: (1) create a new component class that can be a subclass of an existing component; (2) implement a method that renders the HTML content of the component; (3) define the server-side and client-side methods that implement the runtime behavior of the component; and (4) make sure the class includes the CSS-style definitions needed to specify the visual appearance of the component.

How to Localize Zen Application for Different Languages

If desired, Zen automatically maintains a set of all text values (titles, captions, etc.) displayed by an application’s incorporated components in a special localization table. You can export the application’s localization table as an XML document, translate the values to other languages, and import the new tables.

At run time, Zen uses the text values based on the current language preference of the user’s browser.

SVG Support

SVG (Scalable Vector Graphics) provides a powerful, standard way to display rich graphical data within a Web page. Zen includes the ability to create graphical components that render themselves using SVG and includes a rich set of pre-built SVG-based components.

What Browsers Does Zen Support?

Zen works with Firefox (v1.5 and above) and Internet Explorer (v6.0 and above). For Firefox, no plug-ins are required – SVG is built in. For Internet Explorer, the Adobe SVG plug-in is needed if you wish to use Zen’s SVG components. The library manages the differences between Firefox SVG and Internet Explorer.

THE CACHÉ ADVANTAGE Rich Web User Interfaces: Visually sophisticated, highly interactive pages can be generated that are visually more similar to GUI client/server applications than a traditional simple browser form with a SUBMIT button. The user finds the interactive format more natural and easier to use. Fast Object-based Development: The utilization of pre-built components speeds development and makes it simpler to modify later. Consistent User Interfaces: The component-based architecture makes it easier to define and enforce application-wide style and behavior guidelines.

---

InterSystems Corporation
World Headquarters
One Memorial Drive
Cambridge, MA 02142-1356

Tel: +1.617.621.0600
Fax: +1.617.494.1631

www.InterSystems.com

InterSystems Caché is a registered trademark of InterSystems Corporation. Other product names are trademarks of their respective vendors.
Copyright © 2007 InterSystems Corporation. All rights reserved. 07-07

InterSystems Caché Technology Guide

Previous Page Chapter 3

Table of Contents

Next Page