I n s i d e We b O b j e c t s

WebObjects Overview


May 2001
 Apple Computer, Inc. Simultaneously published in the
© 2000-2001 Apple Computer, Inc. United States and Canada
All rights reserved.
No part of this publication may be Even though Apple has reviewed this
reproduced, stored in a retrieval manual, APPLE MAKES NO
system, or transmitted, in any form or WARRANTY OR REPRESENTATION,
by any means, mechanical, electronic, EITHER EXPRESS OR IMPLIED, WITH
photocopying, recording, or RESPECT TO THIS MANUAL, ITS
otherwise, without prior written QUALITY, ACCURACY,
permission of Apple Computer, Inc., MERCHANTABILITY, OR FITNESS
with the following exceptions: Any FOR A PARTICULAR PURPOSE. AS A
person is hereby authorized to store RESULT, THIS MANUAL IS SOLD “AS
documentation on a single computer IS,” AND YOU, THE PURCHASER, ARE
for personal use only and to print ASSUMING THE ENTIRE RISK AS TO
copies of documentation for personal ITS QUALITY AND ACCURACY.
use provided that the documentation IN NO EVENT WILL APPLE BE LIABLE
contains Apple’s copyright notice. FOR DIRECT, INDIRECT, SPECIAL,
The Apple logo is a trademark of INCIDENTAL, OR CONSEQUENTIAL
Apple Computer, Inc. DAMAGES RESULTING FROM ANY
Use of the “keyboard” Apple logo DEFECT OR INACCURACY IN THIS
(Option-Shift-K) for commercial MANUAL, even if advised of the
purposes without the prior written possibility of such damages.
consent of Apple may constitute
THE WARRANTY AND REMEDIES SET
trademark infringement and unfair
FORTH ABOVE ARE EXCLUSIVE AND
competition in violation of federal
IN LIEU OF ALL OTHERS, ORAL OR
and state laws.
WRITTEN, EXPRESS OR IMPLIED. No
No licenses, express or implied, are Apple dealer, agent, or employee is
granted with respect to any of the authorized to make any modification,
technology described in this book. extension, or addition to this warranty.
Apple retains all intellectual property
rights associated with the technology Some states do not allow the exclusion or
described in this book. This book is limitation of implied warranties or
intended to assist application liability for incidental or consequential
developers to develop applications damages, so the above limitation or
only for Apple-labeled or exclusion may not apply to you. This
Apple-licensed computers warranty gives you specific legal rights,
and you may also have other rights which
Every effort has been made to ensure
vary from state to state.
that the information in this document
is accurate. Apple is not responsible
for typographical errors.
Apple Computer, Inc.
1 Infinite Loop
Cupertino, CA 95014
408-996-1010
Apple, the Apple logo, Mac, and
WebObjects are trademarks of Apple
Computer, Inc., registered in the
United States and other countries.
Enterprise Objects and Enterprise
Objects Framework are trademarks of
NeXT Software, Inc., registered in the
United States and other countries.
 Contents

Figures and Tables 7

Chapter 1 About This Book 9

Why Read This Book 9

Further Investigations 10
Other Apple Publications 10
Installed Developer Documentation 11
Information on the Web 12

Chapter 2 What Is WebObjects? 13

Dynamic HTML Publishing 13

Web-Enabled Client-Server Applications 16
HTML-Based WebObjects Applications 16
Java Client Applications 17
Rapid Development 19
Direct to Web 19
Direct to Java Client 20
The WebObjects Advantage 20
Streamlined Database Access 20
Separation of Presentation, Logic, and Data 21
State Management 21
Modular Development 22
Pure Java 22
Scalability and Performance 22

3
 Apple Computer, Inc. May 2001
 C O N T E N T S

Chapter 3 Enterprise Objects 25

What Is an Enterprise Object? 25

Enterprise Objects and the Model-View-Controller Paradigm 28
Mapping Your Enterprise Objects to Database Tables 29
WebObjects Support for Enterprise Objects 32
The Enterprise Objects Advantage 34

Chapter 4 HTML-Based Applications 37

A Programmer’s View of WebObjects 37

Separating HTML and Code 38
Dynamic HTML Elements 39
Reusing Components 40
Maintaining State 41
Separating Web Interface Code from Business Logic 41
WebObjects Architecture 43
Developing a WebObjects HTML Application 44
Project Builder 45
WebObjects Builder 46
Guidelines for Choosing the HTML-Based Approach 47

Chapter 5 Direct to Web Applications 49

How Direct to Web Works 55

Developing a Direct to Web Application 57
The Direct to Web Assistant 58
Further Customizing Your Direct to Web Application 59
Advantages of the Direct to Web Approach 60
Limitations 61
Guidelines for Choosing Direct to Web 62

4
 Apple Computer, Inc. May 2001
 C O N T E N T S

Chapter 6 Java Client Applications 63

Java Client Architecture 64

Managing the User Interface 65
Data Synchronization Between Client and Server 67
Other Architectures 69
Client JDBC Architecture 69
JDBC Three-Tier Architecture 70
Development Tasks and Tools 70
Designing Enterprise Objects for Java Client 71
Creating the User Interface 71
Advantages of the Java Client Approach 73
Limitations 73
Guidelines for Choosing Java Client 74

Chapter 7 Direct to Java Client Applications 75

The Basics 76
Direct to Java Client Architecture 76
Development Tasks and Tools 78
The Direct to Java Client Assistant 78
Further Customizing Your Application 79
Advantages of the Direct to Java Client Approach 80
Limitations 80
Guidelines for Choosing Direct to Java Client 81

Chapter 8 Choosing Your Approach 83

Internet and Intranet Deployment 83

User Interface Requirements 84
Rich Widget Selection and Fast Response Times 84
Specific Layout and Flow Requirements 84
Rapid Development Considerations 85
Combining Approaches 86
Combining HTML-based and Java Client Approaches 86
Adding Rapid Development 87
Summary 87
Where to Go From Here 88

5
 Apple Computer, Inc. May 2001
 C O N T E N T S

Glossary 89

Index 95

6
 Apple Computer, Inc. May 2001
 Figures and Tables

Chapter 2 What Is WebObjects? 13

Figure 2-1 A static publishing site 14

Figure 2-2 A dynamic publishing site 15
Figure 2-3 A website running Java Client applications 18
Figure 2-4 Multiple instances, multiple applications 23

Chapter 3 Enterprise Objects 25

Figure 3-1 Connecting enterprise objects to data and the user interface 27
Figure 3-2 Mapping between an enterprise object class and a single table 30
Figure 3-3 Mapping relationships 31
Figure 3-4 Implementing business logic in enterprise objects 34
Figure 3-5 Implementing business logic in the user interface application 35
Figure 3-6 Implementing business logic in the database 36

Chapter 4 HTML-Based Applications 37

Figure 4-1 The files of a WebObjects component 39

Figure 4-2 How enterprise objects relate to a WebObjects component 42
Figure 4-3 WebObjects HTML-based application communication chain 43
Figure 4-4 Project Builder 45
Figure 4-5 WebObjects Builder 46
Table 4-1 Example Dynamic Elements 40

Chapter 5 Direct to Web Applications 49

Figure 5-1 A login page 49

Figure 5-2 A query-all page 50
Figure 5-3 A query page 51
Figure 5-4 A list page 52

7
 Apple Computer, Inc. May 2001
 F I G U R E S A N D T A B L E S

Figure 5-5 An inspect page 52

Figure 5-6 An edit page 53
Figure 5-7 An edit relationship page 53
Figure 5-8 The menu header 54
Figure 5-9 An example Neutral look page 54
Figure 5-10 An example WebObjects look page 55
Figure 5-11 Determining attributes from the entity 56
Figure 5-12 The Direct to Web rule system 57
Figure 5-13 The Direct to Web Assistant 58
Figure 5-14 The Rule Editor 59

Chapter 6 Java Client Applications 63

Figure 6-1 A sample Java Client application 63
Figure 6-2 Java Client’s distributed, multitier architecture 64
Figure 6-3 Architecture of a Java Client application 66
Figure 6-4 Data flow in a Java Client application 68
Figure 6-5 Composing a user interface with Interface Builder 72

Chapter 7 Direct to Java Client Applications 75

Figure 7-1 A sample Direct to Java Client application 75

Figure 7-2 The components of a Direct to Java Client application 77
Figure 7-3 The Direct to Java Client Assistant 79

8
 Apple Computer, Inc. May 2001
 C H A P T E R 1

1 About This Book

WebObjects is an application server with tools, technologies and capabilities to

create internet and intranet applications. It has an object-oriented architecture that
promotes quick development of reusable components. WebObjects is extremely
scalable and supports high transaction volumes.

This book introduces the architecture, technologies, development tools, and

development approaches of WebObjects to developers and others interested in how
WebObjects works.

Why Read This Book

WebObjects System Overview is written for developers who want to start using
WebObjects. However, anyone interested in WebObjects technology will get
something out of this book.

For the most part, this book does not assume you have a background in
object-oriented programming. However, WebObjects is based on object-oriented
frameworks written in Java, an object-oriented language. You should be familiar
with object-oriented programming if you intend to write WebObjects applications.
There are many books available on the subject if you aren’t.

A hallmark advantage of WebObjects is the database connectivity it provides. To

fully appreciate this technology, you should have some understanding of databases
(although this book doesn’t require it). Again, there are many books available on the
subject.

Why Read This Book 9

 Apple Computer, Inc. May 2001
 C H A P T E R 1

About This Book

Because WebObjects provides four distinct approaches to developing applications,

this book discusses them one by one, and compares their pros and cons to help the
developer decide which approach is appropriate for his or her application.

This book has the following chapters:

■ What Is WebObjects? Introduces the technologies of WebObjects and how they
fit together.
■ Enterprise Objects. Describes the objects that lie at the heart of all WebObjects
applications and encapsulate your application’s business logic and data.
■ HTML-Based Applications. Describes the approach that allows you to create
HTML applications for the World Wide Web.
■ Direct To Web Applications. Describes the rapid development version of the
HTML-based application approach.
■ Java Client Applications. Describes the approach with which you can produce
a graphical user interface application that runs on a client machine.
■ Direct to Java Client Applications. Describes the rapid development version of
the Java Client approach.
■ Choosing Your Approach. Summarizes the pros and cons of these approaches,
and then outlines the process you should go through to decide which approach
or combination of approaches is appropriate for your particular WebObjects
application.

Further Investigations

This book serves as a starting point. It surveys the technologies of WebObjects

without providing the details. This section lists sources of WebObjects information
for software developers. It is by no means an exhaustive list, and Apple’s
contribution to this list will grow.

Other Apple Publications

Apple is planning a series of documents, of which this document is the first in the
series. The rest of the documents are

10 Further Investigations
 Apple Computer, Inc. May 2001
C H A P T E R 1

About This Book

■ Discovering WebObjects HTML

■ Discovering Java Client
■ Discovering Direct to Web
■ Discovering Direct to Java Client
■ Creating Enterprise Objects

After you choose an approach, you should read the appropriate document (when it
becomes available). Regardless of the approach you use, you should read Creating
Enterprise Objects as the material pertains to all approaches.

With the exception of Discovering WebObjects HTML, which is available now, these
documents are in preparation at the time of this writing. You can obtain other
documents in this series (as they become available) using the publish-on-demand
arrangement Apple has with Fatbrain.com.

To obtain a printed copy of one of these documents, use your Web browser to access
the page at www1.fatbrain.com/documentation/apple. Then follow the directions.
The document should be delivered to you within a few business days.

Installed Developer Documentation

When you install the WebObjects Developer on your computer, the Installer puts
developer documentation into the following locations:
■ Frameworks. Information inextricably associated with a framework is usually
installed in a localized subdirectory of the framework. This method of
packaging ensures that the documentation moves with the framework when
and if it moves (or is copied) to another location. It also makes it possible to have
localized versions of the documentation (although English currently is the only
supported localization).
■ Development applications. Help information for applications such as Project
Builder and Interface Builder is installed with the application. When users
request it from the Help menu, the application launches Help Viewer to display
it.
■ Example code. A variety of sample programs are installed in /Developer/
Examples/JavaWebObjects ($NEXT_ROOT/Developer/Examples/JavaWebObjects on
Windows 2000) showing you how to perform common tasks using WebObjects.

Further Investigations 11
 Apple Computer, Inc. May 2001
 C H A P T E R 1

About This Book

■ All information that is not specific to frameworks or development applications

is installed in /Developer/Documentation ($NEXT_ROOT/Documentation/Developer
on Windows 2000). On Mac OS X, the Installer also creates symbolic links to the
framework documentation in this location.

To access the developer documentation on Mac OS X, you use a special interface of

the Help Viewer called the Developer Help Center. Use the following steps to access
the Developer Help Center:

1. Choose Help Center from the Help menu in the Finder.

2. Click the Developer Center link on the first (home) page of the Help Center.
3. To return to the Help Center, click the Help Center link on the home page of the
Developer Help Center.

To access the developer documentation on Windows 2000, you use the

WOInfoCenter application. To access the WOInfoCenter, go to the Start menu and
select Program > WebObjects > WOInfoCenter.

Information on the Web

Apple maintains several websites where developers can go for general and
technical information on WebObjects.
■ Apple Product Information (www.apple.com/webobjects). Provides general
information on WebObjects.
■ Apple Developer Connection—Developer Documentation
(developer.apple.com/techpubs/webobjects). Features the same documentation
that is installed with WebObjects, except that often the documentation is more
up-to-date. This location also includes legacy documentation.
■ Apple Developer Connection—Technical Notes (developer.apple.com/
technotes). Collects late breaking information and supplementary
documentation.
■ AppleCare Tech Info Library (til.info.apple.com). Contains technical articles,
tutorials, FAQs, technical notes, and other information.

12 Further Investigations
 Apple Computer, Inc. May 2001
 C H A P T E R 2

2 What Is WebObjects?

From an information technology perspective, WebObjects is a scalable,

high-availability, high-performance application server. From the viewpoint of a
developer, though, WebObjects is an extensible object-oriented platform upon
which you can rapidly develop and deploy Web applications that integrate existing
data and systems. WebObjects is especially suited to dynamically publishing data
on the World Wide Web and bringing the increased connectivity of the Web to
traditional client-server and desktop applications.

The Web was created to simplify access to electronically published documents.

Originally just static text pages with hyperlinks to other documents, Web pages
quickly evolved into highly graphical animated presentations. Along the way, a
degree of interactivity was introduced, allowing people browsing the Web to fill out
forms and thereby supply data to the server.

WebObjects allows you to take the next logical step. With it, you can produce
full-fledged Web-accessible applications, for use either across the Internet or within
a corporate intranet. These applications can be HTML-based, and thus accessible
through a Web browser, or can have the full interactivity of a stand-alone
application.

Dynamic HTML Publishing

Much of the content on the Web is textual or graphical material that doesn’t change
much over time. However, there is increasing demand for sites that publish
ever-changing data: breaking news stories, up-to-the-minute stock quotes, or the
current weather are good examples.

Dynamic HTML Publishing 13

 Apple Computer, Inc. May 2001
 C H A P T E R 2

What Is WebObjects?

A typical website is organized like Figure 2-1. A user’s Web browser requests pages
using URLs (Uniform Resource Locators). These requests are sent over the network
to the Web server, which analyzes each request and selects the appropriate Web
page to return to the user’s browser. This Web page is simply a text file that contains
HTML. Using the HTML tags embedded within the file received from the Web
server, the browser renders the page.

Figure 2-1 A static publishing site

Web Web Web

browser browser browser

Request
http://www.apple.com
Response
HTML page

<HTML>
<Head>
.
Web server .
.

Static HTML pages

Static publishing sites are easy to maintain. There are a number of tools on the
market that allow you to create HTML pages with a relatively small amount of
effort, and as long as the page content doesn’t change too often, it isn’t that difficult
to keep them up-to-date. Dynamic publishing sites, however, are a different story.
Without WebObjects it could take a small army to keep a breaking news site up to
date.

WebObjects was designed from the beginning to allow you to quickly and easily
publish dynamic data over the Web. You create HTML templates that indicate
where on the Web page the dynamic data is to be placed, and a WebObjects
application fills in the content when your application is accessed. The process is
much like a mail merge. The information your Web pages publish can reside in a
database, it can reside in some other permanent data storage (files, perhaps), or it
can even be calculated or generated at the time a page is accessed. The pages are
also highly interactive—you can fully specify the way the user navigates through
them.

14 Dynamic HTML Publishing

 Apple Computer, Inc. May 2001
C H A P T E R 2

What Is WebObjects?

Figure 2-2 shows a WebObjects-based dynamic publishing site. Again, the request
(in the form of a URL) originates with a client browser. If the Web server detects that
the request is to be handled by WebObjects, it passes the request to a WebObjects
adaptor. The adaptor packages the incoming request in a form the WebObjects
application can understand and forwards it to the application. Based upon
templates you’ve defined and the relevant data from the data store, the application
generates an HTML page that it passes back through the adaptor to the Web server.
The Web server sends the page to the client browser, which renders it.

Figure 2-2 A dynamic publishing site

Web Web Web

browser browser browser

Request
http://store.apple.com/...
Response
HTML page

Web server Static

HTML
pages
WebObjects
adaptor

WebObjects Templates
application

Relational database

Dynamic HTML Publishing 15

 Apple Computer, Inc. May 2001
 C H A P T E R 2

What Is WebObjects?

This type of WebObjects application is referred to as “HTML-based,” since the

result is a series of dynamically generated HTML pages.

Web-Enabled Client-Server Applications

Although the majority of websites primarily publish static data, the number of sites
that publish dynamic content is growing rapidly. Many corporations use intranets,
the Internet, or both to provide easy access to internal applications and data. An
online store selling books, music, or even computers is one example of a
Web-enabled client-server application.

Web-enabled applications can have huge advantages over traditional applications.

Clients don’t have to install the application, which not only saves client disk space
but ensures that the user always has the most up-to-date version of the application.
As well, the client computers can be Macintosh computers, PCs, or workstations—
anything that can run a Web browser with the necessary capabilities.

WebObjects allows you to develop two different flavors of Web-enabled

application: HTML-based applications and Java Client applications. HTML-based
applications are analogous to Common Gateway Interface (CGI) applications and
consist of dynamically-generated HTML pages accessed through a Web browser.
Java Client moves part of your application to the client-side computer and enlists
Sun’s Java Foundation Classes (JFC) to give it the rich user interface found in a more
traditional desktop application.

HTML-Based WebObjects Applications

When you need to develop a HTML-based application like a shopping cart, you can
create it quickly and easily with the WebObjects development tools. WebObjects
supplies a large number of prebuilt components—Web pages, or portions of Web
pages, from which you can build your Web application’s interface. These
components range from simple user interface widgets (for example, submit buttons,
checkboxes, and tables) to complex ones (for example, toolbars). The set of
components that you can use with WebObjects is extensible, so you can create
components that can be reused across all of your Web applications.

16 Web-Enabled Client-Server Applications

 Apple Computer, Inc. May 2001
C H A P T E R 2

What Is WebObjects?

Your application isn’t entirely built of components. You create WebObjects

applications from a combination of components and Java classes. You put your
application-specific business logic in some of these classes. WebObjects provides
the rest of them.

The basic structure of an HTML-based Web application matches that of a dynamic

publishing site that uses WebObjects. Thus, Figure 2-2 (page 15) applies to
HTML-based Web applications as well.

Java Client Applications

When you need the fast and rich user interface of desktop client-server applications,
you can partition your application so that a portion of it—including all or part of the
user interface—runs in Java directly on the client. Client-server communication is
handled by WebObjects. WebObjects applications that are partitioned in this way
are known as Java Client applications.

Java Client distributes the objects of your WebObjects application between the
application server and one or more clients—typically Java applications. It is based
on a distributed multi-tier client-server architecture where processing duties are
divided between a client, an application server, a database server, and a Web server.
With a Java Client application, you can partition business objects containing
business logic and data into a client side and a server side. This partitioning can
improve performance and at the same time help to secure legacy data and business
rules.

Figure 2-3 (page 18) illustrates a Java Client application in which the client portion
is running as an application installed on the user’s computer. As with an
HTML-based WebObjects application, the application can communicate with the
server side using HTTP. In addition, Java Client passes objects between a portion of
your application residing on the user’s computer and the portion of your
application that remains on the application server.

Web-Enabled Client-Server Applications 17

 Apple Computer, Inc. May 2001
 C H A P T E R 2

What Is WebObjects?

Figure 2-3 A website running Java Client applications

WebObjects WebObjects WebObjects

application application application
(client portion) (client portion) (client portion)

HTTP

<HTML>
<Head>
Web server .
.
.

WebObjects Static HTML pages

adaptor

WebObjects WebObjects WebObjects

application application application
(server portion) (server portion) (server portion)

Relational database

Java Client allows your application to look and feel like a traditional desktop
application and still take full advantage of the power of WebObjects.

18 Web-Enabled Client-Server Applications

 Apple Computer, Inc. May 2001
 C H A P T E R 2

What Is WebObjects?

Rapid Development

WebObjects is both powerful and flexible. With that power and flexibility, however,
comes a certain degree of complexity. For many applications, whether HTML-based
or Java Client–based, it’s more important to develop the application quickly than
strive for maximum flexibility or polish. As an example, a simple data-browsing
and editing application, intended only for internal use by a system administrator,
probably wouldn’t warrant the same degree of effort you would put into an
Internet-enabled application accessible by the general public. To simplify the
development of applications like the former, WebObjects includes a set of
rapid-development technologies: Direct to Web and Direct to Java Client.

Direct to Web and Direct to Java Client are similar in approach. Their primary
difference is in how the application interacts with the end user. Direct to Web
creates HTML-based WebObjects applications, whereas Direct to Java Client creates
WebObjects applications that employ Java Client to partition the application
between server and client. Both are useful not only for “quick and dirty”
applications, but in many situations can also serve as rapid prototyping tools.
Because Direct to Web and Direct to Java Client both allow customization on
various levels, they are well-suited for bootstrapping and creating your
mission-critical applications.

Direct to Web
Direct to Web is a configurable system for creating HTML-based WebObjects
applications that access a database. All Direct to Web needs to create the application
is a model for the database, which you can build using EOModeler.

Direct to Web applications are not a set of static Web pages. Instead, Direct to Web
uses information from the model available at runtime to dynamically generate the
pages. Consequently, you can modify your application’s configuration at runtime—
using the Direct to Web Assistant—to hide objects of a particular class, hide their
properties, reorder the properties, and change the way they are displayed without
recompiling or relaunching the application.

Rapid Development 19
 Apple Computer, Inc. May 2001
 C H A P T E R 2

What Is WebObjects?

Out of the box, Direct to Web generates Web pages for nine common database tasks,
including querying, editing, and listing. To do this, Direct to Web uses a
task-specific component called a template that can perform the task on any entity.
The templates, in conjunction with a set of developer-configurable rules, are the
essential elements of your Direct to Web application.

Direct to Web is highly customizable. For example, you can change the appearance
of the standard templates, mix traditional HTML-based WebObjects components
with Direct to Web pages, and create custom components and templates that
implement specialized behavior.

Direct to Java Client

Like Direct to Web, Direct to Java Client generates a user interface for common
database tasks using rules to control program flow, and it has an Assistant that
allows you to modify your applications at runtime. The primary difference between
Direct to Web and Direct to Java Client is the type of application each produces:
Direct to Java Client produces Java Client applications that have the fast and rich
user interfaces associated with desktop applications. Thus, Direct to Java Client
applications have the same client-side requirements that other Java Client
applications do.

The WebObjects Advantage

WebObjects encapsulates a number of key technologies that give it a significant

advantage over other application servers.

Streamlined Database Access

Much of the data that is (or could be) presented on the Web already exists in
electronic form. Not only can it be a challenge to create a website or Web application
to present your data using conventional tools, it can also be a challenge just to access
the data itself. Some products rely on hand- or assistant-generated SQL (Structured
Query Language), leading to database-specific code that is difficult to optimize.
WebObjects avoids these problems by using Enterprise Objects, a model-based

20 The WebObjects Advantage

 Apple Computer, Inc. May 2001
C H A P T E R 2

What Is WebObjects?

mechanism for cleanly instantiating business objects directly from database tables.
WebObjects handles all the interactions with the database including fetching,
caching, and saving. This allows you to write your business logic against actual
objects independent of the underlying data source. You can modify schemas, add
or change databases, or even use totally a different storage mechanism without
needing to rewrite your application.

WebObjects applications can access any database with a JDBC 2.0 driver. JDBC is an
interface between Java platforms and databases.

Separation of Presentation, Logic, and Data

An ideal Web application development system simplifies maintenance and
encourages code reuse by enforcing a clean separation of presentation (HTML),
logic (Java), and data (SQL). This modularity is inherent in the WebObjects
programming model, which uses reusable components to generate Web pages
directly from enterprise objects without the need to embed scripts or Java code
inside your HTML. A component contains a template, which you—or a professional
Web designer—can design and edit using standard Web authoring tools. A
component can also implement custom behavior using a separate Java source file.
Neither the template or the Java source file includes model-specific information.

State Management
The HTTP protocol used on the Web is inherently stateless; that is, each HTTP
request arrives independently of earlier requests, and it’s up to Web applications to
recognize which ones come from an individual user or session. Therefore, most
Web applications of consequence—as well as some of the more interesting dynamic
publishing sites—need to keep state information, such as login information or a
shopping basket, associated with each user session.

Without using cookies, WebObjects provides objects that allow you to maintain
information for the life of a particular client session, or longer. This makes it
particularly easy to implement an application like a Web-based online store: you
don’t have to do anything special to maintain the contents of the user’s shopping
cart or other data over the life of the session. In addition, your online store could
even monitor individual customer buying patterns and then highlight items they’re
more likely to be interested in the next time they visit your site.

The WebObjects Advantage 21

 Apple Computer, Inc. May 2001
 C H A P T E R 2

What Is WebObjects?

Modular Development
The power of WebObjects comes from a tightly integrated set of tools and
frameworks, facilitating the rapid assembly of complex applications. At the heart of
this system is the Project Builder Integrated Development Environment (IDE),
which manages your Java business logic and tracks all the supporting models and
components. As mentioned above, WebObjects also includes powerful assistants
and frameworks that allow the rapid creation of HTML or Java Client applications
directly from the database. Advanced developers can tap into the object-oriented
Java APIs underlying all the different frameworks, allowing virtually unlimited
customization and expandability.

Pure Java
WebObjects applications are 100% Pure Java, which means they can be deployed on
any platform with a certified Java 2 virtual machine.

Scalability and Performance

Static websites and traditional client-server applications have one strong suit: they
both leverage the power of the client platform, minimizing the load on the server. It
doesn’t take all that much processing power to serve up a set of static Web pages.
Dynamic Web applications, although a tremendous advance over static pages,
require additional server power to access the dynamic data and construct the Web
pages or Java Client user interface “on the fly.”

The WebObjects application server is both efficient and scalable. With WebObjects,
if more power, reliability, or failover protection is needed, you can run multiple
instances of your application, either on one or on multiple application servers (see
Figure 2-4 (page 23)). You can choose from one of several load-balancing algorithms
(or create your own) that determine which instance each new user should connect
to. And, either locally or from a remote location, you can analyze site loads and
usage patterns and then start or stop additional application instances as necessary.
Load balancing is a very powerful feature of WebObjects that allows you to add
more server capacity as the need arises without needing to implement a
load-balancing algorithm yourself.

22 The WebObjects Advantage

 Apple Computer, Inc. May 2001
C H A P T E R 2

What Is WebObjects?

Figure 2-4 Multiple instances, multiple applications

Web server

WebObjects
adaptor

Application 1 Application 2 Application 1 Application 2

Instance 2 Instance 3 Instance 4 Instance 5

Application 1 Application 2 Application 1 Application 1

Instance 1 Instance 2 Instance 3 Instance 4

Application server 2
Application 1
Instance 1

Application server 1

The WebObjects Advantage 23

 Apple Computer, Inc. May 2001
 C H A P T E R 2

What Is WebObjects?

24 The WebObjects Advantage

 Apple Computer, Inc. May 2001
 C H A P T E R 3

3 Enterprise Objects

As mentioned in the previous chapter, WebObjects applications gain much of their

usefulness by interacting with a persistent store, that is, a database. In WebObjects,
databases are represented as collections of objects called enterprise objects.
Enterprise objects contain the bulk of your application’s business logic, the part of
the application you write regardless of which of the four approaches you take.

This chapter introduces enterprise objects, describes how they map to a database,
outlines how WebObjects supports and interacts with them, and enumerates the
advantages of the enterprise objects approach over other approaches available in
the industry. The reader may wish to read the first section, “What Is an Enterprise
Object?” (page 25), and the last section, “The Enterprise Objects Advantage”
(page 34), and skip the rest of the chapter, which is written for those familiar with
relational databases.

What Is an Enterprise Object?

An enterprise object is like any other object in that it couples data with the methods
for operating on that data. However, an enterprise object class has certain
characteristics that distinguish it from other classes:
■ It has properties that map to stored or persistent data; an enterprise object
instance typically corresponds to a single row or record in a database.
■ It knows how to interact with other parts of WebObjects to give and receive
values for its properties. This is done through a mechanism known as key-value
coding, which enables the setting and getting of these properties.

What Is an Enterprise Object? 25

 Apple Computer, Inc. May 2001
 C H A P T E R 3

Enterprise Objects

In addition to providing classes that manage a set of enterprise objects in memory,

WebObjects defines an API to which enterprise objects must conform, as well as
default implementations for this API. As a result, you only need to concentrate on
the parts of your enterprise object classes specific to your application.

To maximize the reusability and extensibility of your objects, they shouldn’t embed
knowledge of the user interface or database alongside the business logic. For
example, if you embed knowledge of your user interface, you can’t reuse the objects
because each application’s user interface is different. Similarly, if you embed
knowledge of your database, you’ll have to update your objects every time you
modify the database.

If not in the business objects, then where does this knowledge go? It’s handled by
WebObjects as shown in Figure 3-1 (page 27).

26 What Is an Enterprise Object?

 Apple Computer, Inc. May 2001
C H A P T E R 3

Enterprise Objects

Figure 3-1 Connecting enterprise objects to data and the user interface

Model
WebObjects

Enterprise objects

Relational database

WebObjects provides a database-to-objects mapping, called a model, so your

objects are independent of the database. WebObjects also provides an
objects-to-interface mapping so they are independent of the user interface. This
approach enables you to create libraries of enterprise objects that can be used in as
many applications as you need, with any user interface, and with any database
server. You’re able to concentrate on coding the logic of your business while
WebObjects takes care of the rest.

What Is an Enterprise Object? 27

 Apple Computer, Inc. May 2001
 C H A P T E R 3

Enterprise Objects

For example, you could create a class of enterprise objects called Customer that
defines such business rules as “customers must have a work or home phone
number,” or “the customer cannot spend more than his credit limit.” Without
rewriting your business logic, you could use these objects in a public web-based
application and an internal customer service application. You could also switch the
database that serves the customer data.

Enterprise Objects and the Model-View-Controller

Paradigm
A common and useful paradigm for object-oriented applications, particularly
business applications, is Model-View-Controller (MVC). Derived from
Smalltalk-80, MVC proposes three types of objects in an application, separated by
abstract boundaries and communicating with each other across those boundaries.

Model objects represent special knowledge and expertise. For example, model
objects can hold a company's data and define the logic that manipulates that data.
Model objects are not directly displayed. They often are reusable, distributed,
persistent, and portable to a variety of platforms.

Note: WebObjects uses the term “model” differently from MVC. In WebObjects,
a model establishes and maintains a correspondence between an enterprise object
class and data stored in a relational database. In MVC, model objects represent the
special knowledge of the application.

View objects represent things visible on the user interface (windows, for example,
or buttons). A View object is “ignorant” of the data it displays. View objects tend to
be very reusable and so provide consistency between applications.

Acting as a mediator between Model objects and View objects in an application is a

Controller object. There is usually one per application or window. A Controller
object communicates data back and forth between the Model objects and the View
objects. Since what a Controller does is very specific to an application, it is generally
not reusable even though it often comprises much of an application's code.

Because of the Controller's central mediating role, Model objects need not know
about the state and events of the user interface, and View objects need not know
about the programmatic interfaces of the Model objects.

28 What Is an Enterprise Object?

 Apple Computer, Inc. May 2001
 C H A P T E R 3

Enterprise Objects

From the perspective of this paradigm, enterprise objects are Model objects.
However, WebObjects also extends the MVC paradigm. Enterprise objects are also
independent of their persistent storage mechanism. Enterprise objects do not need
to know about the database that holds their data, and the database doesn’t need to
know about the enterprise objects formed from its data.

Mapping Your Enterprise Objects to Database Tables

Enterprise objects make use of a separate file, known as a model, to specify a

mapping between tables in the database and your classes of enterprise objects. This
is formally called an entity-relationship (E-R) model. You use the EOModeler
application to create and maintain these models. With EOModeler you can
■ read the data dictionary from a database to create a default model, which can
then be tailored to suit the needs of your application
■ specify enterprise object classes for the tables in your database
■ specify relationships between enterprise objects and referential integrity rules
for these relationships
■ generate source code files for the enterprise object classes you specify
■ define fetch specifications (queries) that you can invoke by name in your
applications
■ create and delete databases and database tables

A model represents a level of abstraction above the database. The

database-to-objects mapping embodied in a model sets up a correspondence
between database tables and enterprise objects classes; frequently, database rows
map to instances of the appropriate class as shown in Figure 3-2 (page 30).

Mapping Your Enterprise Objects to Database Tables 29

 Apple Computer, Inc. May 2001
 C H A P T E R 3

Enterprise Objects

Figure 3-2 Mapping between an enterprise object class and a single table

lastName "Farina"
Talent
firstName "Dennis"

TALENT
TALEN ME
T _I D L A S T _N A M E FIRST_NA
1 028 Dennis
Farina
1 132 Corey
Feldman

In actual practice, the mapping is more flexible than this. For example:
■ You can map an enterprise object class to a single table, a subset of a table, or to
more than one table. For instance, a Person object can get its first and last names
from a PERSON table but get its street address, city, state and zip code from an
ADDRESS table.
■ Generally an enterprise object instance variable maps to a single column, but the
column-to-instance variable correspondence is similarly flexible. You can map
an instance variable to a derived column, such as “price * discount” or “salary *
12”.
■ You can map an enterprise object class inheritance hierarchy to one or more
database tables.

In addition to mapping tables to enterprise object classes and database columns to

instance variables, WebObjects maps database primary and foreign keys to
relationships between objects. WebObjects defines two types of relationships—

30 Mapping Your Enterprise Objects to Database Tables

 Apple Computer, Inc. May 2001
C H A P T E R 3

Enterprise Objects

to-ones and to-manys—which are both illustrated in Figure 3-3. The relationship a
MovieRole has to its Movie is a to-one relationship, while the relationship a Movie
has to its MovieRoles is a to-many.

Figure 3-3 Mapping relationships

movieRoles
NSMutableArray

movie
Movie MovieRole

movie
MovieRole

M O VIE _ R O LE MOVIE
TALEN
T _ I D M O VIE _ R IT L E
OLE MOVIE_ID MOVIE_ID T
1 028
R iple y 501 501 Alien
o
1132
A sh 501 703 Toy St

Mapping Your Enterprise Objects to Database Tables 31

 Apple Computer, Inc. May 2001
 C H A P T E R 3

Enterprise Objects

WebObjects Support for Enterprise Objects

After your program has accumulated changes to enterprise objects, WebObjects

analyzes the objects for changes, generates corresponding database operations, and
executes those operations to synchronize the database with in-memory enterprise
objects. WebObjects has mechanisms for ensuring that the integrity of your data is
maintained between your application and the database without sacrificing
performance or flexibility:

Validation
A good part of your application’s business logic is usually validation—
for example, verifying that customers don’t exceed their credit limits,
return dates don’t come before their corresponding check-out dates, and
so on. In your enterprise object classes, you implement methods that
check for invalid data, and WebObjects automatically invokes them
before saving anything to the database.
Referential integrity enforcement
In your model you can specify rules governing the relationships
between objects, such as whether a to-one relationship is optional or
mandatory. You can also specify delete rules—actions that should occur
when an enterprise object is deleted. For example, if you have a
“department” object you can specify that when it is deleted all the
employees in that department are also deleted (a cascading delete), all
the employees in that department are updated to have no department
(nullify), or the department deletion is rejected if it has any employees
(deny).
Automatic primary and foreign key generation
You needn’t maintain database artifacts such as database primary and
foreign key values in your application; WebObjects keeps track of them
for you. Database primary and foreign keys aren’t usually meaningful
parts of a business model; rather, they’re attributes created in a
relational database to express relationships between entities. Key values
can be generated and propagated automatically.

32 WebObjects Support for Enterprise Objects

 Apple Computer, Inc. May 2001
C H A P T E R 3

Enterprise Objects

Transaction management
Most transactions are handled for you, using the native transaction
management features of your database to group database operations
that correspond to the changes that have been made to enterprise objects
in memory. You don’t have to worry about beginning, committing, or
rolling back transactions unless you want to fine-tune transaction
management behavior. WebObjects also provides a separate in-memory
transaction management feature that allows you to create nested
contexts in which a child context’s changes are folded into the parent
context only upon successful completion of an in-memory operation.
Locking
WebObjects offers three types of locking. “Pessimistic” uses your
database server’s native locking mechanism to lock rows as they’re
fetched and prevents update conflicts by never allowing two users to
look at the same object at the same time. “Optimistic” doesn’t detect
update conflicts until you try to save an object’s changes to the database;
if the corresponding database row has changed since it was originally
fetched, the save is aborted. “On-Demand” is a mixture of the other two:
it locks an object after you fetch it but before you attempt to modify it.
The lock can fail for one of two reasons: either the corresponding
database row has changed since you fetched the object (optimistic
locking), or because someone else already has a lock on the row
(pessimistic locking).
Faulting
When WebObjects fetches an object, it creates objects representing the
destinations of the fetched object’s relationships. By default WebObjects
doesn’t immediately fetch data for the destination objects of
relationships, however. Fetching is fairly expensive, and further, if
WebObjects fetched objects related to the one explicitly asked for, it
would also have to fetch the objects related to those, and so on, until all
of the interrelated rows in the database had been retrieved. For many
applications, this would be a waste of time and resources. To avoid this,
WebObjects creates empty destination objects, called faults, that fetch
their data the first time they’re accessed. This process, known as
“faulting,” is automatic.
Uniquing
In marrying relational databases to object-oriented programming, one
of the key requirements is that a row in the database be associated with
only one enterprise object in a given context in your application.
WebObjects maintains the mapping of each enterprise object to its

WebObjects Support for Enterprise Objects 33

 Apple Computer, Inc. May 2001
 C H A P T E R 3

Enterprise Objects

corresponding database row, and uses this information to ensure that,

within a given context, your object set does not include two (possibly
inconsistent) objects for the same database row. Uniquing of enterprise
objects, as this process is called, reduces memory usage and allows you
to know with confidence that the object you’re interacting with
represents the true state of its associated row as it was last fetched.

The Enterprise Objects Advantage

A hallmark feature of WebObjects, especially in comparison to other solutions, is

the separation of the business logic from the database and the user interface. In
WebObjects, you put the business logic in the enterprise objects (Figure 3-4).

Figure 3-4 Implementing business logic in enterprise objects

Application

.......
.......
...
WebObjects Business logic
.....
..... .......

Relational database

34 The Enterprise Objects Advantage

 Apple Computer, Inc. May 2001
C H A P T E R 3

Enterprise Objects

Another approach (Figure 3-5) is to implement business logic in the web or desktop
application. The WebObjects approach betters this approach in the following ways:
■ It offers greater reuse. In WebObjects, you code your business logic once, and
each application that accesses your database can use it. You don’t have to recode
your business logic into each screen or web page.
■ It’s more maintainable. With WebObjects, you don’t have to duplicate your
business logic. Thus you can easily make substantial changes to your rules
without resorting to finding and fixing every affected page in every affected
application. You can also easily track changes to your schema.
■ It improves data integrity. In WebObjects, you don’t need to rely on all
application developers to implement the business rules correctly. If one
application has an error, it is less likely to corrupt your database.
■ It scales better. In WebObjects, you can improve your application’s
performance without having to provide your users with faster systems. Instead,
you can simply move some computation-intensive processing to fast server
machines.

Figure 3-5 Implementing business logic in the user interface application

Application

Business logic

Relational database

Another approach (Figure 3-6) is to implement your business rules in the

database—with stored procedures, rules, constraints, and triggers, for example. The
WebObjects approach betters this approach in the following ways:

The Enterprise Objects Advantage 35

 Apple Computer, Inc. May 2001
 C H A P T E R 3

Enterprise Objects

■ It offers improved interactivity. If you implement your business rules in the

database, you need to make a round trip to the database every time the user
performs an action. Alternatively, you can batch up database changes, which
prevents the user from receiving immediate feedback. In WebObjects
applications, changes immediately appear in the user interface, but you access
the database only when saving these changes or fetching objects.
■ It improves back-end portability. Database vendors all have different ways to
implement logic. If you have to support more than one database and you’re
using WebObjects, you don’t have to implement the logic multiple times and
thus suffer maintenance problems.
■ Java is a good development language. With WebObjects, you program in Java,
an industrial-strength language designed from the ground up to be
object-oriented. The programmable variants of SQL usually have some
object-oriented features but are basically procedural languages.

Figure 3-6 Implementing business logic in the database

Application

Relational
Business logic
Database

36 The Enterprise Objects Advantage

 Apple Computer, Inc. May 2001
 C H A P T E R 4

4 HTML-Based Applications

The HTML-based application approach allows you to create applications that

dynamically generate HTML pages. WebObjects provides graphical tools and a set
of flexible frameworks with which you can develop extremely complex
applications. This chapter describes how a WebObjects HTML application works,
the parts of a WebObjects application the programmer sees, the advantages of using
this approach, and what the development process is like.

A Programmer’s View of WebObjects

The following features of WebObjects ease the development of HTML-based Web

applications:
■ The HTML and code reside in separate files. An object called a component
represents a Web page and consists of separate files for HTML and Java code.
■ WebObjects provides dynamic versions of static HTML elements. These are
called dynamic elements.
■ You can reuse HTML and code. Components can be embedded within other
components as if they were dynamic elements.
■ WebObjects automatically maintains state information. WebObjects
overcomes the inherent statelessness of HTTP and maintains session state (like
a shopping cart) and application state (like application statistics).
■ Your Web interface code remains separate from your business logic.
Enterprise objects, discussed in Chapter 3, contain all of your business logic.
This allows you to reuse your business logic in multiple Web pages and even
multiple applications.

A Programmer’s View of WebObjects 37

 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

These advantages are discussed in more detail in the sections that follow.

Separating HTML and Code

In WebObjects, a Web page is represented by a component, an object that has both
content and behavior. A component can also represent a portion of a page but
usually represents an entire page, so the word “page” is used interchangeably with
the word “component.”

Components consist of
■ a template in HTML that specifies how the component looks. This file can be
edited by any HTML editor or text editor.
■ code that specifies how the component acts. You specify this with a standard
Java source file.
■ bindings that associate the component’s template with its code. These are
stored in a text file.

Separating the template, code, and bindings makes it much easier to maintain a
website. A graphic artist can modify a template, thus modifying the appearance of
the page, without breaking the code. A programmer can completely rearrange the
code without accidentally changing the layout.

You do not need to edit all three files separately. WebObjects Builder, a graphical
component editing tool provided with WebObjects, edits the template, bindings,
and code files simultaneously, relieving you of having to manually synchronize
them. WebObjects Builder is described in more detail in “WebObjects Builder”
(page 46).

Figure 4-1 (page 39) shows the three files in an example component.

38 A Programmer’s View of WebObjects

 Apple Computer, Inc. May 2001
C H A P T E R 4

HTML-Based Applications

Figure 4-1 The files of a WebObjects component

Component (Greeting.wo)
Template (Greeting.html)
<HTML>
<HEAD><TITLE>Greeting</TITLE></HEAD>
<BODY>
Hello <WEBOBJECT NAME=String1></WEBOBJECT>!
<P></BODY>
</HTML>

Code (Greeting.java)

import com.webobjects.appserver.*;

public class Greeting extends WOComponent {

protected String userName;

public Greeting(WOContext context) {

super(context);
}

public String userName() {

return userName;
}

public void setUserName(String newUserName) {

userName = newUserName;
}
}

Bindings (Greeting.wod)

String1 : WOString {
value = userName;
}

Dynamic HTML Elements

The template file in Figure 4-1 looks like any other HTML file except for the element
with the <WEBOBJECT> tag. In this example, this tag represents a dynamic element.
Dynamic elements are basic building blocks of a WebObjects application. They link
an application’s behavior with the HTML page shown in the Web browser, and
their contents are defined at runtime. A dynamic element appears in the template

A Programmer’s View of WebObjects 39

 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

as a <WEBOBJECT> tag with a corresponding </WEBOBJECT> closing tag. Some dynamic

elements have no HTML counterpart; WORepetition and WOConditional are
examples. Table 4-1 lists some of the more commonly used dynamic elements.

Table 4-1 Example Dynamic Elements

Element Name Description

WOBrowser A selection list that displays multiple items at a time.
WOCheckBox A checkbox user interface control.
WOConditional Controls whether a portion of the HTML page will be
generated.
WOForm A container element that generates a fill-in form.
WOHyperlink Generates a hypertext link.
WOImage Displays an image.
WORadioButton Represents a toggle switch.
WORepetition A container element that repeats its contents (that is,
everything between the <WEBOBJECT...> and
</WEBOBJECT...> tags in the template file) a given
number of times.
WOResetButton A button that clears a form.
WOString A dynamically generated string.
WOSubmitButton A submit button.
WOText A multiline field for text input and display.
WOTextField A single-line field for text input and display.

Reusing Components
You can embed a component within another component. For example, a component
might represent only a header or footer of a page; you can nest it inside of a
component that represents the rest of the page. A component designed to be nested
within another component is called a reusable component, shared component, or
subcomponent. Like dynamic elements, reusable components appear in the

40 A Programmer’s View of WebObjects

 Apple Computer, Inc. May 2001
C H A P T E R 4

HTML-Based Applications

template as a <WEBOBJECT> tag with a corresponding </WEBOBJECT> closing tag,

allowing you to extend WebObjects’ repertoire of dynamically generated HTML
elements.

The WOExtensions Framework provided with WebObjects contains many useful

reusable components like tables, radio button matrices, tab panels, and collapsible
content. In addition, Direct to Web provides reusable components for editing,
listing, selecting, inspecting, and querying enterprise objects.

Maintaining State
In addition to the components, each WebObjects application has a number of
sessions and an application object.

A session is a period during which a particular user is accessing your application.

Because users on different clients may be accessing your application at the same
time, a single application may host more than one session at a time. Session objects
encapsulate the state of a single session. These objects persist beyond the HTTP
request-response cycles, and store (and restore) the pages of a session, the values of
session variables, and any other state that components need to persist throughout a
session. In addition, each session has its own copy of the components that its user
has requested.

Session variables can be used in shopping cart applications to represent the items in
the shopping cart. Email applications can use session variables to keep track of
whether the user has logged in or not.

The application object is responsible for interfacing to an adaptor and forwarding

HTTP requests to a dispatcher that, in turn, passes them to the appropriate session
and component. The application object also passes the HTML response from the
active component back to the adaptor. In addition, the application object manages
adaptors, sessions, application resources, and components.

Separating Web Interface Code from Business Logic

In HTML-based WebObjects applications (as in all WebObjects applications), the
enterprise objects encapsulate the application’s business logic and provide the
connection with the application’s databases. Since enterprise objects are objects,
they can appear as variables in components, sessions, or the application object. A

A Programmer’s View of WebObjects 41

 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

component’s bindings file relates the component’s enterprise objects to the

attributes of its dynamic elements. Figure 4-2 shows how enterprise objects relate to
a component in a WebObjects application.

Figure 4-2 How enterprise objects relate to a WebObjects component

Server
Component

Template
..... partNum W4378
........
Bindings color Red
size XL
..... retail 48.99
... .....
Code

42 A Programmer’s View of WebObjects

 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

WebObjects Architecture

When you run a WebObjects application, it communicates with the Web browser
through the chain of processes shown in Figure 4-3.

Figure 4-3 WebObjects HTML-based application communication chain

Web
browser

Web server

WebObjects
adaptor

WebObjects
application

WebObjects

SQL Data

Relational database

WebObjects Architecture 43
 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

Here is a brief description of these processes:

■ A Web browser. WebObjects supports all Web browsers that conform to HTML
3.2. Of course, if your application uses more advanced features like JavaScript or
QuickTime, the users’ browsers must support these features.
■ A Web server. WebObjects supports any HTTP server that uses the Common
Gateway Interface (CGI), the Netscape Server API (NSAPI), the Internet Server
API (ISAPI), or the Apache module API. Although necessary for deployment,
you don’t actually need a Web server while you develop your WebObjects
applications.
■ A WebObjects adaptor. A WebObjects adaptor connects WebObjects
applications to the Web by acting as an intermediary between Web applications
and HTTP servers. Note that the WebObjects adaptor may not be a separate
process but plug-in to the Web server.
■ A WebObjects application process. The application process receives incoming
requests and responds to them, usually by returning a dynamically generated
HTML page. You can run multiple instances of this process if one instance is
insufficient to handle the application load. The application process is made up
of your code and the WebObjects frameworks.

Developing a WebObjects HTML Application

Developing a WebObjects application is a matter of creating your templates,

bindings, and Java code files. Although these files are text based and thus could be
created using a text editor, WebObjects provides graphical tools that simplify the
entire process. The sequence of tasks used to create a WebObjects HTML
application with these tools is as follows:
■ Create a project using Project Builder.
■ Create a model using EOModeler.
■ Edit your components with WebObjects Builder.

You have already been introduced to EOModeler. Project Builder and WebObjects
Builder are discussed in the following sections.

44 Developing a WebObjects HTML Application

 Apple Computer, Inc. May 2001
C H A P T E R 4

HTML-Based Applications

Project Builder
As its name implies, Project Builder manages all of the constituent parts of your
application, including source code files, WebObjects components, frameworks,
makefiles, graphics and sound files, and the like. You use Project Builder to edit
your code files, compile, debug, and launch your application for development
testing. Project Builder’s assistants help you create new WebObjects components.
You also can launch the other development tools from within Project Builder.

Figure 4-4 (page 45) shows Project Builder in use.

Figure 4-4 Project Builder

Developing a WebObjects HTML Application 45

 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

WebObjects Builder
You use WebObjects Builder to edit your application’s components. WebObjects
Builder allows you to graphically edit a component’s HTML template. If you prefer,
you can switch to the source view from which you can edit the template as an
HTML text file. WebObjects Builder also allows you to graphically bind the
dynamic elements on your template to variables and methods within your code;
you simply drag from a variable to the dynamic element as shown in Figure 4-5
(page 46).

Figure 4-5 WebObjects Builder

46 Developing a WebObjects HTML Application

 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

Guidelines for Choosing the HTML-Based Approach

The WebObjects HTML approach has the following advantages:

■ Portability. Any user with a Web browser can access a WebObjects HTML
application.
■ Flexibility. You can create extremely complex HTML applications with the
WebObjects HTML approach.
■ Reduced System Administration. With the HTML-based application approach,
you can publish data such as breaking news and stock prices without having to
rewrite the HTML each time, reducing the number of people necessary to keep
the site up to date.

In some cases, you can use the Direct to Web rapid development system to create
your HTML-based application for you. Direct to Web works particularly well for
data-driven applications, prototypes, and internal applications. See “Direct to Web
Applications” (page 49) for more information.

Guidelines for Choosing the HTML-Based Approach 47

 Apple Computer, Inc. May 2001
 C H A P T E R 4

HTML-Based Applications

48 Guidelines for Choosing the HTML-Based Approach

 Apple Computer, Inc. May 2001
 C H A P T E R 5

5 Direct to Web Applications

Direct to Web is a technology that creates HTML-based Web applications that use
enterprise objects and consequently access databases. All you need to provide is the
model that specifies the database-to-objects mapping and Direct to Web instantly
creates an application.

Direct to Web applications have a particular structure. Every Direct to Web

application begins on a login page (Figure 5-1). By default, this page provides an
interface to authenticate the user but does not actually perform any authentication.
Because the login page is a standard WebObjects component, you can change its
behavior.

Figure 5-1 A login page

49
 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

After the user logs in, Direct to Web displays its first dynamically generated page:
a query-all page (Figure 5-2). This page allows the user to specify the enterprise
objects he or she wants to work with. The user can query for any type of enterprise
object that is visible in the application (the developer decides which types are visible
and which are not).

Figure 5-2 A query-all page

If the query-all page is not specific enough, the user can click one of the hyperlinks
labeled “more..”, which brings up a query page specific to the corresponding type
of enterprise object (Figure 5-3). In this page, the user can specify the values for
several properties at the same time. The resulting query is the logical “and” of the
individual queries for the properties.

50
 Apple Computer, Inc. May 2001
C H A P T E R 5

Direct to Web Applications

Figure 5-3 A query page

When the user clicks the Query button on the query page or the magnifying glass
icon on the query-all page, Direct to Web displays the enterprise objects matching
the query on a list page (Figure 5-4). This page presents the enterprise objects in
batches; the user can change the batch size and navigate from batch to batch.

51
 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

Figure 5-4 A list page

Note that each Movie enterprise object on the list page in Figure 5-4 has an Edit
button, which indicates that Movie objects are read-write. The developer can
configure whether a type of enterprise object is read-only or read-write.

If the Movie objects are read-only, an Inspect button appears on each row instead of
an Edit button. If the user clicks the Inspect button next to one of the enterprise
objects, Direct to Web displays an inspect page for the object (Figure 5-5) that
reveals more detailed information about the object.

Figure 5-5 An inspect page

If the objects displayed on the list page are writable and the user clicks the Edit
button next to one of them, Direct to Web displays an edit page for the object (Figure
5-6). On the edit page, the user can edit the attributes for the object or click the Edit
button next to one of the relationships to edit the relationship.

52
 Apple Computer, Inc. May 2001
C H A P T E R 5

Direct to Web Applications

Figure 5-6 An edit page

The user edits a relationship using an edit-relationship page (Figure 5-7), which
edits to-many and to-one relationships.

Figure 5-7 An edit relationship page

With the exception of the login page, every Direct to Web page has an area
containing a menu and buttons that assist in navigating around the application
(Figure 5-8). This is called the menu header.

53
 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

Figure 5-8 The menu header

Every Direct to Web application appears in one of three looks. A look is a visual
theme, and affects the layout and appearance of the pages. The example pages you
have seen are in the Basic look. Direct to Web also supports two other looks: the
Neutral look (Figure 5-9) and the WebObjects look (Figure 5-10 (page 55)).

Figure 5-9 An example Neutral look page

54
 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

Figure 5-10 An example WebObjects look page

How Direct to Web Works

As you have seen, Direct to Web applications have a fixed structure. They consist of
a set of task pages (for example, query, list, and edit pages) that work for any type
of enterprise object. These task pages are created using special WebObjects
components called Direct to Web templates.

A Direct to Web template uses information from the entities of the enterprise objects
it displays. An entity is the piece of the model that specifies how a table maps to a
specific enterprise object. The Direct to Web template takes advantage of the entity’s
property information (that is, information about the entity’s attributes and
relationships) and determines the properties it needs to display. For example, a
Direct to Web template displaying a list page for Movie objects can determine that
it needs to display the title, release date, category, and other attributes for each
movie on the page (Figure 5-11).

How Direct to Web Works 55

 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

Figure 5-11 Determining attributes from the entity

Server

...
partNum W4378

...
Product attributes color Red
.. . size XL
.. .
Name External type
. ..

retail 48.99
...

partNum VARCHAR2 ..
color VARCHAR2 . . . ....
..
size VARCHAR2
retail NUMBER
Product entity Product objects

Direct to Web applications can be configured using a Java applet called the Direct
to Web Assistant. The configuration information is stored as a database of rules.
Rules say something like “if the task page is a list page and the entity is the Movie
entity, do not display the banner.” Each rule has a priority and rules with higher
priority override rules with lower priority. Direct to Web defines a set of default
rules that define the basic application behavior. You can define higher priority rules
that override the default rules for special cases. This is exactly what the Direct to
Web Assistant does. Figure 5-12 shows the relationship between the Direct to Web
template, the rule system, the rule database, and the Direct to Web Assistant.

56 How Direct to Web Works

 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

Figure 5-12 The Direct to Web rule system

Web Assistant

Server
Direct to Web
template

Template Rules

Bindings Rule system

Code

Note that when you configure your application with the Direct to Web Assistant,
you don’t need to recompile your code to try your changes. Direct to Web is not a
code generation wizard. It generates Web pages at runtime based on the templates
and the rules.

Developing a Direct to Web Application

There are four steps to creating a Direct to Web application:

■ Create a Direct to Web project using Project Builder.
■ Create a model using EOModeler.

Developing a Direct to Web Application 57

 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

■ Customize your Direct to Web application using the Direct to Web Assistant
(optional).
■ Further customize your Direct to Web application (optional).

Of the four steps, the last two are unique to Direct to Web and are discussed in more
detail below.

The Direct to Web Assistant

The Direct to Web Assistant is a Java applet that runs at the same time as your
application. It communicates directly with Direct to Web and allows you to
reconfigure your application in many ways. Figure 5-13 (page 58) shows the Direct
to Web Assistant in use.

Figure 5-13 The Direct to Web Assistant

With the assistant, you can designate which entities are read-write, read-only, or
hidden. You can also set appearance parameters for most of the pages that Direct to
Web generates. For example, you can control whether or not the page displays with
a banner. You can also change the background color for the table the page displays,
if applicable. The assistant also permits you to configure the way properties
(attributes and relationships) appear on list, edit, and inspect pages.

58 Developing a Direct to Web Application

 Apple Computer, Inc. May 2001
C H A P T E R 5

Direct to Web Applications

As mentioned earlier, the assistant defines a set of rules that override the default
Direct to Web rules. Thus, the assistant is the preferred way to modify rules.
However, sometimes you need to change the default rules or override the default
rules in ways the assistant can’t. You can use an application called the Rule Editor
to edit the rules directly. Figure 5-14 shows the Rule Editor.

Figure 5-14 The Rule Editor

Further Customizing Your Direct to Web Application

If you need to customize your application beyond what you can do with the Direct
to Web Assistant, you can use these methods:

Developing a Direct to Web Application 59

 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

■ Freeze a page. When you want to change the appearance or function of a single
page in your Direct to Web application, you can freeze the page with the Direct
to Web Assistant. The page becomes a WebObjects component in your project
with a HTML template, a Java source file, and a bindings file. You can edit it
with WebObjects Builder just as you would any other component. The
downside is that you can’t customize frozen pages with the Direct to Web
Assistant.
■ Generate a Direct to Web template. Sometimes you need to change the way
every page for a particular task appears in your application. For example, you
might want to put an extra hyperlink at the bottom of every list page. To do so,
you instruct the Direct to Web Assistant to generate a Direct to Web template,
modify the template, and tell the assistant to use your customized template
instead of the standard one. As mentioned earlier, a Direct to Web template is an
ordinary WebObjects component and can be edited using WebObjects Builder.
Unlike frozen pages, Direct to Web pages based your custom template can be
customized with the assistant.
■ Modify the page wrapper and menu header. The page wrapper component is
included in your project and determines the text and elements that are common
to every page in your application except the login page. It contains the menu
header appropriate for the look. Figure 5-8 (page 54) shows the menu header for
the Basic look. The menu header is another component in your project.
■ Mix WebObjects and Direct to Web pages. You can navigate to a Direct to Web
page from a WebObjects page and vice versa. You can also embed certain Direct
to Web functions within a WebObjects page. These capabilities extend the
flexibility of Direct to Web considerably.
■ Perform other customizations. You can change almost anything in a Direct to
Web application because it is just a WebObjects application with some extra
functionality. However, you need to know the details of the Direct to Web
architecture.

Advantages of the Direct to Web Approach

Direct to Web applications are just specialized HTML-based WebObjects

applications and so they have the same advantages: portability and reduced system
administration. What Direct to Web adds to the HTML-based WebObjects approach

60 Advantages of the Direct to Web Approach

 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

is the ability to dynamically generate all of the Web pages, relieving you of
designing and coding them yourself. As a consequence, Direct to Web has the
following advantages over the HTML-based WebObjects approach:
■ It flattens the learning curve for developing applications.
■ It reduces the time required to develop applications.
■ It reduces the likelihood of errors.
■ It increases the maintainability and adaptability of applications.
■ It increases prototyping capabilities.
■ It allows you to focus on business logic instead of on the user interface.

Also, Direct to Web applications are constructed using well-tested Apple

technology, which increases the stability of applications and reduces the time
required to test applications before deploying them.

Limitations

Direct to Web is an HTML-based technology. As a result, Direct to Web user

interfaces are highly portable but suffer the limited interactivity provided by HTML
forms.

Because Direct to Web generates your applications for you, the applications have a
number of additional limitations.

First, the programming model is indirect. You provide a model and Direct to Web
assembles the application for you. The Web page generation is performed by a
“magic box.” You don’t have to know what’s going on. This makes it really easy to
get started programming with Direct to Web. But for certain customizations, the
learning curve gets very steep very fast.

The machinery for generating Web pages is an entirely new layer on top of the
WebObjects HTML-based application technology. This layer adds complexity that
regular HTML-based applications don’t have, and you might have to learn the
details of it to get certain results. In fact, making fundamental changes to a Direct to
Web application can be a lot of work. Note, however, that you can typically reuse
this work in later applications.

Limitations 61
 Apple Computer, Inc. May 2001
 C H A P T E R 5

Direct to Web Applications

Another disadvantage is that modifying the layout of a Direct to Web template is

more involved and harder to do than laying out a WebObjects component because
Direct to Web templates are more complex than most WebObjects components.

Guidelines for Choosing Direct to Web

If your application requires a fast graphical user interface similar to that of a

desktop application, you need to use one of the Java Client approaches (Java Client
or Direct to Java Client). Direct to Web produces HTML-based applications.

Direct to Web is particularly suited for mission-critical applications, prototypes,

and intranet applications where development time is critical and the limitations that
Direct to Web imposes on the flow and user interface are not an issue. Although you
can customize the application, you first need to familiarize yourself with the
WebObjects HTML-based application approach and possibly Direct to Web.

Once you are familiar with how Direct to Web works, you can also use the Direct to
Web reusable components in a standard WebObjects HTML-based website. This
technique can dramatically reduce the development time for certain types of pages
like forms and list pages.

62 Guidelines for Choosing Direct to Web

 Apple Computer, Inc. May 2001
 C H A P T E R 6

6 Java Client Applications

The Java Client approach allows you to replace the HTML user interface of a
WebObjects application with a much more interactive and flexible one written in
Java. In the sample Java Client application shown in Figure 6-1, the user interface is
like the interfaces you see in traditional desktop applications.

Figure 6-1 A sample Java Client application

63
 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

Java Client Architecture

The Java Client architecture differs from the HTML-based WebObjects architecture
in that it’s distributed across client and server systems as shown in Figure 6-2. The
server-side portion interacts with a database server and the client-side portion
provides all or part of the application’s user interface.

Figure 6-2 Java Client’s distributed, multitier architecture

Client
computer WebObjects
(user’s system)
application
(client-side)

Web server

Application
server WebObjects
application
(server-side)

Relational database

64 Java Client Architecture

 Apple Computer, Inc. May 2001
C H A P T E R 6

Java Client Applications

The client and server applications have duties other than merely providing the user
interface and database access—for example, each can contain business logic and
each communicates with the other through a Web server. However, the database
access/user interface division is significant because it provides a richness of user
interface without compromising security or performance. Sensitive business logic
and database connection logic is provided only by the server application. Because
compiled Java on the client side can be decompiled, the client application is limited
to user interface code and nonsensitive business logic. At the same time, the ability
to put some of the business logic on the client (any nonsensitive logic) improves
performance. By performing as much processing as possible on the client (such as
field validation), round trips to the server are limited.

Managing the User Interface

Unlike in HTML-based applications, the WebObjects component of the server-side
application doesn’t have to provide any user interface management. Instead, the
Java Client architecture moves part or all of the user interface management to a
client application, as shown in Figure 6-3 (page 66). To support this division, the
Java Client architecture duplicates the graph of enterprise objects on the client
application so the graph and its management occur on both server and client.
WebObjects handles all client-server communication and distributes the object
graph across client and server.

Java Client Architecture 65

 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

Figure 6-3 Architecture of a Java Client application

Client
JFC

Custom code
WebObjects

Web server

Server
Model Custom code
WebObjects

JDBC

Relational database

The user interface itself is implemented using Java Foundation Classes (JFC). This
is what gives a Java Client application the appearance and functionality of a
traditional desktop application. WebObjects maps data between the application’s
user interface and the graph of enterprise objects. Changes to the object graph are
automatically synchronized with the user interface and user-entered data is
automatically reflected in the object graph.

66 Java Client Architecture

 Apple Computer, Inc. May 2001
C H A P T E R 6

Java Client Applications

Data Synchronization Between Client and Server

Figure 6-4 (page 68) shows the flow of data between the client and server
applications for the Java Client architecture.

Starting in the upper left of the diagram and working down, when the client
application initiates a fetch, the client application forwards the corresponding fetch
specification to the server application. From there the normal mechanisms take over
and an SQL query is performed in the database server.

Working back up the diagram on the right side, the database server returns the rows
of requested data and, as usual, this data is converted to enterprise objects. The
server then sends copies of the requested objects to the client. When the client
receives the objects, it updates its user interface with values from the requested
objects.

Java Client Architecture 67

 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

Figure 6-4 Data flow in a Java Client application

Client
Client side user interface

..... partNum W4378

........
WebObjects color Red
size XL
..... retail 48.99
.. ......

Web server

Server .
. . ...... partNum W4378
Model .. . . . color Red
WebObjects size XL
.. retail 48.99
.. . . . .. ... whole 25.00
..

Relational database

Although requested objects are copied from the server to the client, and these
objects exist in parallel object graphs on both server and client, the enterprise objects
on the client usually do not exactly mirror the enterprise objects on the server. The
objects on the client usually have a subset of the properties of the objects on the
server. You can partition your application’s enterprise objects so the objects that
exist on the client have a restricted set of data and behaviors. This ability allows you
to restrict sensitive data and business logic to the server. For example, in Figure 6-4,
the client side enterprise objects don’t have the “whole” property, the price the
seller paid to the manufacturer.

68 Java Client Architecture

 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

Once the client has fetched data, this data is cached and is represented internally by
the client’s object graph. As users modify the data (or delete or add “rows” of data),
the client application updates the client’s object graph to reflect the new state. When
the client application initiates a save, the changed objects are “pushed” to the server.
If the business logic on the server validates these changes, the changes are
committed to the database.

Note that Java Client automatically updates the client with changes that have
occurred on the server. Whenever the client makes a request, the server passes
updates along to the client with whatever information the client requested.
Similarly, Java Client has the opportunity to update the client before client-side
objects remotely invoke methods on server-side objects.

Other Architectures

There are other Java-based architectures besides Java Client that are also distributed
and mutiltier. This section describes how Java Client compares with the Client
JDBC and JDBC three-tier architectures.

Client JDBC Architecture

Client JDBC applications use the same “fat-client” architecture that desktop
applications do. Custom code invokes JDBC on the client, which in turn goes
through a driver to communicate with a JDBC proxy on the server; this proxy makes
the necessary client-library calls on the server. The shortcomings of this type of
architecture are typical of all fat-client architectures. Security is a problem because
the compiled Java on the client is easily decompiled, leaving both sensitive data and
business rules at risk. The server has to be open to allow all client operations
without being able to control what the client is doing. In addition, such an
architecture doesn’t scale; it is expensive to move data over the channel to the client.

Java Client has none of these problems. Sensitive data and business rules can be
confined to the server, so the server doesn’t have to allow indiscriminate access to
data and operations. Additionally, because the client part of a Java Client
application contains nonsensitive data and business logic, it doesn’t make nearly as
many round trips to the server or move as much data back and forth.

Other Architectures 69
 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

JDBC Three-Tier Architecture

A JDBC three-tier application (with CORBA as the transport) is a big improvement
over Client JDBC. In this architecture the client can be thin because all that is
required on the client side is the JFC, non-sensitive custom code (usually for
managing the user interface), and CORBA stubs for communicating with the server.
Sensitive business logic as well as logic related to database connection are stored on
the server. In addition, the server handles all data-intensive computations.

Although the JDBC three-tier architecture is an improvement over Client JDBC, it

has its own weaknesses.
■ The JDBC three-tier architecture results in too much network traffic. Because this
architecture uses “proxy” business objects on the client as handles to the real
objects on the server, each client request for an attribute is forwarded to the
server, causing a separate round trip and precipitating a “message storm.”
■ The JDBC three-tier architecture requires developers to write much of the code
themselves, from code for database access and data packaging to code for
user-interface synchronization and change tracking.
■ The JDBC three-tier architecture does not provide much of the functionality
associated with application servers, such as application monitoring and load
balancing, nor does it provide HTML integration.

Java Client addresses these problems as well. First, instead of using proxy business
objects on the client, the Java Client application makes use of “copies” of the objects.
Second, WebObjects provides all of the database access and user interface
synchronization with its enterprise objects technology. Finally, it provides
application server functionality and HTML integration.

Development Tasks and Tools

The most basic tasks of creating a Java Client application are as follows:
■ Create a project using Project Builder.
■ Create a model using EOModeler.
■ Write source code for enterprise object classes.

70 Development Tasks and Tools

 Apple Computer, Inc. May 2001
C H A P T E R 6

Java Client Applications

■ Create your application’s user interface with Interface Builder.

■ Write source code for any application-level logic.

The tasks have much in common with those for developing HTML-based
WebObjects applications. The major differences are the way you design your
enterprise object classes and the way you create your application’s user interface.

Designing Enterprise Objects for Java Client

Java Client allows you to specify two enterprise object classes for each entity: one
for the server and one for the client. The client and server classes can have different
sets of properties and business logic. This means that programming a Java Client
WebObjects application requires a specific design technique that isn’t necessary in
HTML-based development: object partitioning. Simply put, you have to determine
whether you need different enterprise object classes for the client and the server and
also what data and business logic to put in each class.

Usually, client objects have the more restricted set of data and behaviors, but it is
really up to you to decide based on the requirements of the application and your
business. As noted earlier, the primary criteria for partitioning are performance and
security.

Creating the User Interface

A Java Client WebObjects application gives you considerable flexibility in how you
compose its user interface. Ideally you provide an application’s entire user interface
in a single Java application that runs on the client. But you can also combine Java
Client applets and static and dynamic (WebObjects) HTML elements in various
ways. You can have pages with or without Java Client applets or pages with
multiple Java Client applets. For example, you could have a login page that takes
the user to one of many Java Client pages based on some piece of account data. In
addition, Java Client applets are not limited to the downloaded JFC components; as
with any applet, they can create dialogs and secondary windows on the fly.

If your application’s user interface uses static and dynamically generated HTML,
you create those parts of the user interface in the normal way with WebObjects
Builder (as described in “HTML-Based Applications” (page 37)). The process is

Development Tasks and Tools 71

 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

different for creating a Java Client application or applet. Instead of using

WebObjects Builder to create the user interface, you use an application called
Interface Builder.

Note: If you’re familiar with Cocoa development, the process for creating a Java
Client user interface is nearly the same as the one for creating a Cocoa user
interface for Mac OS X applications.

In Interface Builder, you typically construct a user interface by dragging widgets

from a palette and dropping them into a window, as shown in Figure 6-5. It does
more, however, than simple user interface layout. Interface Builder also lets you
create, edit, and connect objects so they can communicate with one another at
runtime.

Figure 6-5 Composing a user interface with Interface Builder

72 Development Tasks and Tools

 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

Advantages of the Java Client Approach

Java Client applications have much in common with traditional desktop

applications. They also have much in common with HTML-based Web
applications. Correspondingly, Java Client applications have some of the best
features from each:
■ Client-side processing. Web applications do the majority of their processing on
the server, while Java Client moves much of an application’s processing to the
client. This reduces the amount of client-server communication considerably,
making Java Client applications much snappier than their Web counterparts.
■ Rich user interfaces. Like a desktop application, a Java Client application can
draw upon user-interface frameworks that provide endless possibilities for user
interface widgets. Additionally, a Java Client application can have multiple
windows open at once. HTML applications have a more rigid workflow,
allowing only one page of the user interface to be available at a time.
■ Portability. Like any Web application, a Java Client application is portable. A
Web application can run on any client browser that implements certain
standards and protocols. Because a Java Client application is written in Pure
Java, it too runs almost anywhere. The client need only have a compatible Java
virtual machine (VM), something that major operating systems include as a
standard feature.
■ Security. Because sensitive data and business logic are confined to the server in
Web applications, they are more secure than traditional client-server
applications.

Limitations

Java Client applications compare very favorably to traditional desktop applications

and other distributed, multitier, Java-based architectures. They compare favorably
to an HTML-based approach, too, but you trade some of the advantages of an
HTML-based application for an improved user interface.

Advantages of the Java Client Approach 73

 Apple Computer, Inc. May 2001
 C H A P T E R 6

Java Client Applications

The client portion of a Java Client application can take the form of an application or
an applet. The trade-offs are different with each. Providing the client portion as an
application requires more system administration than using an HTML-based
approach. HTML-based Web applications require no software installations on
client systems. Users need only a Web browser to access the applications. With Java
Client applications, however, the application should usually be pre-installed on
client machines.

The alternative to providing the client portion as an application is providing it as an

applet that runs in a browser. The system administration requirements of this
approach are comparable to those of HTML-based Web applications: no client
installations are required. Instead of running a preinstalled application, users
transparently download an applet to a browser in which the applet runs. This
download, however, is the disadvantage of using an applet. No matter how simple
the Java Client user interface is, the size of the applet is considerable. Thus, it takes
longer for a Java Client applet to start up than for a Java Client application; and the
slower the client’s connection is, the longer it takes for the applet to start up.

Guidelines for Choosing Java Client

Some applications simply require the flexibility and interactivity of a Java Client
user interface—an HTML-only solution just isn’t acceptable. However, Java Client
is rarely appropriate for mass markets and highly visible websites. Typically it’s
practical only in intranet environments.

As mentioned in the last section, Java Client applications have special deployment
requirements because part of the application runs on the user’s machine. You either
need to install the client-side application on the user’s machine, which requires
system administration, or the user needs to download the client-side application,
which can take a long time if the network is slow. If neither solution is acceptable,
you need to use the WebObjects HTML-based approach or the Direct to Web
approach.

74 Guidelines for Choosing Java Client

 Apple Computer, Inc. May 2001
 C H A P T E R 7

7 Direct to Java Client Applications

The Direct to Java Client approach provides the richness of a Java Client application
without as much work. Direct to Java Client is an add-on to Java Client that
dynamically generates user interfaces. Instead of designing a user interface for your
application, Direct to Java Client does it for you. Figure 7-1 shows the user interface
of a typical Direct to Java Client application.

Figure 7-1 A sample Direct to Java Client application

75
 Apple Computer, Inc. May 2001
 C H A P T E R 7

Direct to Java Client Applications

The Basics

Direct to Java Client dynamically generates an application’s user interface from

model files. It creates windows for finding, creating, updating, and deleting objects
that correspond to entities in the models. Based on model information, Direct to
Java Client chooses appropriate widgets for representing the properties of objects.

There are numerous ways to customize the default user interface Direct to Java
Client generates, so you can achieve almost any user interface you need.

Direct to Java Client Architecture

Direct to Java Client applications have the same basic architecture as Java Client
applications do. The main difference is the addition of rule files that determine how
Direct to Java Client assembles a user interface for your application.

76 The Basics
 Apple Computer, Inc. May 2001
C H A P T E R 7

Direct to Java Client Applications

Figure 7-2 The components of a Direct to Java Client application

Client
JFC

Custom code
WebObjects

Web server

Server
Model

Custom code
WebObjects
Rules

JDBC

Relational database

Direct to Java Client Architecture 77

 Apple Computer, Inc. May 2001
 C H A P T E R 7

Direct to Java Client Applications

Development Tasks and Tools

The tasks of creating a Direct to Java Client application are similar to writing a
Direct to Web application. There are four steps:
■ Create a Direct to Java Client project using Project Builder.
■ Create a model using EOModeler.
■ Customize your application using the Direct to Java Client Assistant (optional).
■ Further customize your application (optional).

Further information about the last two optional steps is given below.

The Direct to Java Client Assistant

The Direct to Java Client Assistant is the easiest way to customize a Direct to Java
Client application. It is an easy-to-use tool that is integrated into a running client
application. It allows you to perform the most common customizations, directly test
them while the application is running, and save them in your project. The Direct to
Java Client Assistant is very similar in concept to the Direct to Web Assistant even
though the two assistants look and behave differently.

78 Development Tasks and Tools

 Apple Computer, Inc. May 2001
C H A P T E R 7

Direct to Java Client Applications

Figure 7-3 The Direct to Java Client Assistant

Further Customizing Your Application

Writing custom rules is another way to customize your Direct to Java Client
application. It’s very similar to writing custom rules for Direct to Web applications.
As with Direct to Web applications, all the information about how to configure a
Direct to Java Client application is stored in the form of rules. The default rules
generate the default Direct to Java Client application. Adding new rules that
override or supplement the default rules is an easy-to-maintain approach that
doesn’t interfere with your use of the assistant. You write rules with the Rule Editor,
the same application used for writing rules in Direct to Web applications. For more
information, see “Developing a Direct to Web Application” (page 57).

Development Tasks and Tools 79

 Apple Computer, Inc. May 2001
 C H A P T E R 7

Direct to Java Client Applications

There are also some more specialized ways to change the way Direct to Java Client
works. For example, you can get the precise user interface layout for a particular
window by freezing the interface and supplying a nib file (created in Interface
Builder the way you do for regular Java Client applications). As another example,
Direct to Java Client provides hooks you can use to introduce custom commands
into an application’s main menu. Additionally, you can also subclass Direct to Java
Client classes to change the way an application performs a particular task or to add
new functionality to the default set.

Direct to Java Client was designed to be flexible and extensible, so there are
numerous customization approaches. There are simple approaches that are
code-free and maintainable (using the assistant and writing custom rules), there are
more specialized approaches that are complex and require a lot of work, and there’s
everything in between. You can achieve almost any effect that you need. It’s
generally simply a question of which technique to use and what trade-offs you’re
willing to make.

Advantages of the Direct to Java Client Approach

A Direct to Java Client application is really just a specialized Java Client application,
so it has the same advantages: a rich user interface, portability, and security.

In addition, Direct to Java Client creates your application like Direct to Web does.
Thus you get the Direct to Web’s advantages as well: reduced time to develop
applications, increased stability, improved prototyping capabilities, reduced
testing requirements, and the freedom to focus on the business logic instead of the
user interface.

Limitations

Direct to Java Client applications share both the advantages and limitations of Java
Client applications. Thus, Direct to Java Client applications have the disadvantage
of requiring more system administration than HTML-based Web applications.

80 Advantages of the Direct to Java Client Approach

 Apple Computer, Inc. May 2001
 C H A P T E R 7

Direct to Java Client Applications

In addition, Direct to Java Client applications have the advantages and limitations
of Direct to Web. The learning curve is flat until you need to customize your
application; then it becomes very steep. You need to understand the layer of Direct
to Java Client that generates the user interface in addition to the Java Client
technology. Also, detailed widget placement (moving a text field three pixels to the
right, for example) is harder to do with Direct to Java Client than it is with regular
Java Client and Interface Builder.

Finally, Direct to Java Client applications are a little slower than static user
interfaces. When you start up the application or open a new type of window, Direct
to Java Client has to make round trips to the server to get the information it needs
to assemble the user interface. It has numerous optimizations to make user interface
generation fast, but it does incur a performance hit.

Guidelines for Choosing Direct to Java Client

Once you’ve decided an application will have a Java Client user interface, try to use
Direct to Java Client to build the user interface. Direct to Java Client’s advantages
generally outweigh its disadvantages. At least prototype new applications with
Direct to Java Client, and slowly transition to regular Java Client only as needed.

The only time you might choose not to use Direct to Java Client is when you know
that your final application will have a significantly different user interface
paradigm than the one Direct to Java Client uses by default.

Guidelines for Choosing Direct to Java Client 81

 Apple Computer, Inc. May 2001
 C H A P T E R 7

Direct to Java Client Applications

82 Guidelines for Choosing Direct to Java Client

 Apple Computer, Inc. May 2001
 C H A P T E R 8

8 Choosing Your Approach

Choosing between the four WebObjects approaches is the first task you face as a
WebObjects programmer. To make the choice you need to consider the following
issues:
■ Are you planning to deploy over the internet or an intranet?
■ What are your user interface requirements?
■ How quickly do you need to develop the application?

The following sections, “Internet and Intranet Deployment” (page 83), “User
Interface Requirements” (page 84), and “Rapid Development Considerations”
(page 85) explore the approaches in more detail from the perspective of each of
these issues. You can also combine approaches as described in “Combining
Approaches” (page 86).

Internet and Intranet Deployment

The WebObjects HTML approach is the best approach for deploying internet
applications, especially those for highly visible websites. A user on any
internet-enabled computer with a Web browser can access a WebObjects HTML
application.

You can also use Direct to Web to create your application, but the user interface is
generally not flexible enough for public websites. If you’re familiar with
WebObjects and Direct to Web, you can use Direct to Web reusable components to
accelerate the development process. See “Combining Approaches” (page 86) for
more information.

Internet and Intranet Deployment 83

 Apple Computer, Inc. May 2001
 C H A P T E R 8

Choosing Your Approach

Java Client and Direct to Java Client applications are generally unsuitable for public
websites because they contain client code that runs on the user’s computer. Not only
must the user wait for this code to download, but also the quality of the user’s Java
Virtual Machine determines whether the application runs correctly, efficiently, and
attractively.

User Interface Requirements

The WebObjects development approaches differ in the richness and response times
of the user interfaces and the ease in which you can make user interfaces with
specific layout and flow requirements.

Rich Widget Selection and Fast Response Times

The Java Client and Direct to Java Client approaches offer user interfaces with
multiple windows and a large selection of widgets, features commonly found in
client-server applications. If your application needs these features, you should use
one of these approaches. The HTML user interface used by the WebObjects
HTML-based and Direct to Web approaches offers much more limited possibilities.

When you need fast response times from your user interface (if you’re displaying
and updating real time data, for example), you should use the Java Client or Direct
to Java Client approaches. The user’s computer manages the highly interactive user
interface.

The drawback of the Java Client approaches is you need to be sure the client code is
on the user’s computer when the user runs your application. You can either install
it on the user’s computer in advance like a standalone application, which can be
inconvenient, or download it as an applet, which can take a long time.

Specific Layout and Flow Requirements

If you plan to create an HTML application with specific page design and flow
requirements, you should use the WebObjects HTML approach. The alternative,
Direct to Web, creates applications with a predefined structure that limits the user

84 User Interface Requirements

 Apple Computer, Inc. May 2001
 C H A P T E R 8

Choosing Your Approach

interface’s flexibility. Direct to Web is highly customizable, but you need to have a
strong understanding of WebObjects before you can effectively customize the flow
of a Direct to Web application.

Your decision is similar if your application needs the rich and fast user interface the
Java Client approaches offer. If the user interface has specific layout and flow
requirements, you should use the Java Client approach over the Direct to Java
Client approach.

Keep in mind that the Direct to Java Client approach—including the user interface
it generates—is designed expressly for viewing and editing databases, especially
large ones. If your application requires this capability, you will probably find Direct
to Java Client’s user interface extremely well-suited for the task.

Rapid Development Considerations

Using the Direct to Web and Direct to Java Client approaches, you can build an
application with far less time and effort than the WebObjects HTML and Java Client
approaches. You only need to provide the database-to-enterprise objects mapping
(the model) and WebObjects creates your application from it. However, the rapid
development approaches also impose a user interface on your application and you
must be adept at WebObjects and Direct to Web to override it.

There are several types of applications at which the rapid development approaches
excel because their user interface limitations aren’t an issue:
■ Database maintenance tools. These approaches create user interfaces optimized
for administering databases and are therefore well-suited for this type of
application.
■ Prototypes. You can quickly and easily test a model by creating a Direct to Web
or Direct to Java Client application based on the model. Using this application,
you can test whether the relationships and database integrity rules are correct.
■ Internal data driven applications. Direct to Web has been used to develop
in-house applications for bug and feature tracking, customer account
management, and writing online help. Direct to Java Client can be used for such

Rapid Development Considerations 85

 Apple Computer, Inc. May 2001
 C H A P T E R 8

Choosing Your Approach

applications as well. For internal applications, the user interface polish is not as
important as development time, making these applications ideal candidates for
the WebObjects rapid development approaches.

Combining Approaches

WebObjects does not confine you to a single approach. You can switch your
approach as you develop your application or combine it with another approach.
This is possible in WebObjects because the business logic is encapsulated in
enterprise objects and not in the application.

Combining HTML-based and Java Client

Approaches
In general, you shouldn’t combine a HTML-based approach (WebObjects
HTML-based or Direct to Web) with a Java Client approach (Java Client or Direct to
Java Client) because the combination has none of the advantages and all of the
drawbacks of the individual approaches. The speed and interactivity of their user
interfaces are major advantages of Java Client applications. These advantage are
lost when the applications also use inherently less-interactive HTML-based
interfaces.

Similarly, a major advantage of HTML-based applications is that any computer

with a Web browser can use them. When combined with Java Client, these
applications depend on the quality of the browser’s Java Virtual Machine, if the
browser even implements one. In addition, you must install the client code on the
user’s computer or force the user to wait for it to download. The extra interactivity
Java Client adds to the HTML-based approaches is usually outweighed by the
concomitant loss of portability.

86 Combining Approaches
 Apple Computer, Inc. May 2001
 C H A P T E R 8

Choosing Your Approach

Adding Rapid Development

The WebObjects HTML-based and Direct to Web approaches can be combined in
many ways. You can start with a Direct to Web application, freeze and customize
pages, and add your own pages. You can also start with a HTML-based application
and link its components with Direct to Web pages.

Direct to Web also provides reusable components, of which the edit and list
components are used the most. If your application employs forms and lists that
work with enterprise objects, these components can save you a tremendous amount
of time.

You can also mix Java Client and Direct to Java Client applications. If you’re
developing a Java Client application and you need a Direct to Java Client controller
(a window that edits an enterprise object, for example), you can easily instantiate
one. Also, you can freeze an interface in Direct to Java Client and edit it with
Interface Builder.

Summary

The advantages and disadvantages of the four WebObjects development

approaches are summarized in the following paragraphs.

The primary advantage of the WebObjects HTML-based approach is its portability.

Any user with a Web-enabled computer and a Web browser can use the application.
Its disadvantages are the limitations of the HTML-based user interface—delays due
to round trips to the server and a limited widget set.

Direct to Web has the same advantages and limitations of the WebObjects
HTML-based approach. However, it also allows you to develop data-driven
applications extremely quickly. The downside of Direct to Web is that it generates
a particular user interface that may not be suitable for your application.

Java Client applications provide the rich and fast user interfaces of client-server
desktop applications. The disadvantage of this approach is portability. You need to
install or download the application on the user’s computer.

Summary 87
 Apple Computer, Inc. May 2001
 C H A P T E R 8

Choosing Your Approach

Direct to Java Client allows you to quickly develop data-driven Java Client
applications and therefore has the advantages and disadvantages of Java Client.
However, like Direct to Web, Direct to Java Client imposes a particular user
interface that may not be suitable for your application.

Where to Go From Here

Once you have decided upon an approach, you can go to companion documents
that cover the creation of WebObjects applications for each approach. These
documents are
■ Discovering WebObjects HTML
■ Discovering Java Client
■ Discovering Direct to Web
■ Discovering Direct to Java Client

The last three books are in preparation at the time of this writing.

Finally, because the creation of enterprise objects is independent of the approach

you choose, and because there are numerous subtleties in the way you can
implement your enterprise objects, a fifth companion volume (also in preparation)
is dedicated to this subject: Creating Enterprise Objects.

88 Where to Go From Here

 Apple Computer, Inc. May 2001
9 Glossary

adaptor, WebObjects A process (or a part same types of instance variables and have
of one) that connects WebObjects access to the same methods belong to the
applications to an HTTP server. same class.

application object An object (of the column In a relational database, the

WOApplication class) that represents a dimension of a table that holds values for a
single instance of a WebObjects application. particular attribute. For example, a table that
The application object’s main role is to contains employee records might have a
coordinate the handling of HTTP requests, column titled “LAST_NAME” that contains
but it can also maintain application-wide the values for each employee’s last name. See
state information. also attribute.

attribute In Entity-Relationship modeling, component An object (of the

an identifiable characteristic of an entity. For WOComponent class) that represents a web
example, lastName can be an attribute of an page or a reusable portion of one.
Employee entity. An attribute typically
corresponds to a column in a database table. database server A data storage and
See also entity; relationship. retrieval system. Database servers typically
run on a dedicated computer and are
business logic The rules associated with accessed by client applications over a
the data in a database that typically encode network.
business policies. An example is
automatically adding late fees for overdue Direct to Java Client A WebObjects
items. development approach that can generate a
Java Client application from a model.
CGI A standard for interfacing external
applications with information servers, such Direct to Java Client Assistant A tool used
as HTTP or Web servers. Short for Common to customize a Direct to Java Client
Gateway Interface. application.

class In object-oriented languages such as Direct to Web A WebObjects development

Java, a prototype for a particular kind of approach that can generate a HTML-based
object. A class definition declares instance Web applications from a model.
variables and defines methods for all
members of the class. Objects that have the Direct to Web Assistant A tool that used to
customize a Direct to Web application.

89
 Apple Computer, Inc. May 2001
 G L O S S A R Y

Direct to Web template A component used faulting A mechanism used by WebObjects

in Direct to Web applications that can to increase performance whereby destination
generate a web page for a particular task (for objects of relationships are not fetched until
example, a list page) for any entity. they are explicitly accessed.

dynamic element A dynamic version of an fetch In Enterprise Objects Framework

HTML element. WebObjects includes a list of applications, to retrieve data from the
dynamic elements with which you can build database server into the client application,
your component. usually into enterprise objects.

enterprise object A Java object that foreign key An attribute in an entity that
conforms to the key-value coding protocol gives it access to rows in another entity. This
and whose properties (instance data) can attribute must be the primary key of the
map to stored data. An enterprise object related entity. For example, an Employee
brings together stored data with methods for entity can contain the foreign key deptID,
operating on that data. See also key-value which matches the primary key in the entity
coding; property. Department. You can then use deptID as the
source attribute in Employee and as the
entity In Entity-Relationship modeling, a destination attribute in Department to form a
distinguishable object about which data is relationship between the entities. See also
kept. For example, you can have an primary key; relationship.
Employee entity with attributes such as
lastName, firstName, address, and so on. An HTML-based application approach A
entity typically corresponds to a table in a WebObjects development approach that
relational database; an entity’s attributes, in allows you to create HTML-based Web
turn, correspond to a table’s columns. See applications.
also attribute; table.
inheritance In object-oriented
Entity-Relationship modeling A programming, the ability of a superclass to
Discipline for examining and representing pass its characteristics (methods and instance
the components and interrelationships in a variables) on to its subclasses.
database system. Also known as E-R
modeling, this discipline factors a database instance In object-oriented languages such
system into entities, attributes, and as Java, an object that belongs to (is a member
relationships. of) a particular class. Instances are created at
runtime according to the specification in the
EOModeler A tool used to create and edit class definition.
models.
Interface Builder A tool used to create and
edit graphical user interfaces like those used
in Java Client applications.

90
 Apple Computer, Inc. May 2001
 G L O S S A R Y

Java Client A WebObjects development EOModeler application. A model also

approach that allows you to create graphical includes the information needed to connect
user interface applications that run on the to a particular database server.
user’s computer and communicate with a
WebObjects server. Model-View-Controller An
object-oriented programming paradigm in
Java Foundation Classes A set of graphical which the functions of an application are
user interface components and services separated into the special knowledge (Model
written in Java. The component set is known objects), user interface elements (View
as Swing. objects), and the interface that connects them
(the Controller object).
JDBC Informally stands for “Java Database
Connectivity.” An interface between Java object A programming unit that groups
platforms and databases. together a data structure (instance variables)
and the operations (methods) that can use or
key An arbitrary value (usually a string) affect that data. Objects are the principal
used to locate a datum in a data structure building blocks of object-oriented programs.
such as a dictionary.
primary key An attribute in an entity that
key-value coding The mechanism that uniquely identifies rows of that entity. For
allows the properties in enterprise objects to example, the Employee entity can contain an
be accessed by name (that is, as key-value EmpID attribute that uniquely identifies each
pairs) by other parts of the application. employee.

locking A mechanism to ensure that data Project Builder A tool used to manage the
isn’t modified by more than one user at a development of a WebObjects application or
time and that data isn’t read as it is being framework.
modified.
property In Entity-Relationship modeling,
look In Direct to Web applications, one of an attribute or relationship. See also
three user interface styles. The looks differ in attribute; relationship.
both layout and appearance.
record The set of values that describes a
method In object-oriented programming, a single instance of an entity; in a relational
procedure that can be executed by an object. database, a record is equivalent to a row.

model An object (of the EOModel class) referential integrity The rules governing
that defines, in Entity-Relationship terms, the the consistency of relationships.
mapping between enterprise object classes
and the database schema. This definition is
typically stored in a file created with the

91
 Apple Computer, Inc. May 2001
 G L O S S A R Y

relational database A database designed rule In the Direct to Web and Direct to Java
according to the relational model, which uses Client approaches, a specification used to
the discipline of Entity-Relationship customize the user interfaces of applications
modeling and the data design standards developed with these approaches.
called normal forms.
Rule Editor A tool used to edit the rules in
relationship A link between two entities Direct to Web and Direct to Java Client
that’s based on attributes of the entities. For applications.
example, the Department and Employee
entities can have a relationship based on the session A period during which access to a
deptID attribute as a foreign key in WebObjects application and its resources is
Employee, and as the primary key in granted to a particular client (typically a
Department (note that although the join browser). Also an object (of the WOSession
attribute deptID is the same for the source class) representing a session.
and destination entities in this example, it
doesn’t have to be). This relationship would table A two-dimensional set of values
make it possible to find the employees for a corresponding to an entity. The columns of a
given department. See also to-one; to-many; table represent characteristics of the entity
many-to-many; primary key; foreign key. and the rows represent instances of the
entity.
reusable component A component that can
be nested within other components and acts template In a WebObjects component, a file
like a dynamic element. Reusable containing HTML that specifies the overall
components allow you to extend the appearance of a web page generated from the
WebObject’s selection of dynamically component.
generated HTML elements.
to-many relationship A relationship in
request A message conforming to the which each source record has zero to many
Hypertext Transfer Protocol (HTTP) sent corresponding destination records. For
from the user’s Web browser to a Web server example, a department has many employees.
that asks for a resource like a Web page. See
to-one relationship A relationship in
also response.
which each source record has exactly one
response A message conforming to the corresponding destination record. For
Hypertext Transfer Protocol (HTTP) sent example, each employee has one job title.
from the Web server to the user’s Web
transaction A set of actions that is treated
browser that contains the resource specified
as a single operation.
by the corresponding request. The response
is typically a web page. See also request. uniquing A mechanism to ensure that,
within a given context, only one object is
row In a relational database, the dimension
associated with each row in the database.
of a table that groups attributes into records.

92
 Apple Computer, Inc. May 2001
 G L O S S A R Y

validation A mechanism to ensure that

user-entered data lies within specified limits.

WebObjects Builder A tool used to

graphically edit WebObjects components.

93
 Apple Computer, Inc. May 2001
 G L O S S A R Y

94
 Apple Computer, Inc. May 2001
 Index

A D
adaptor (WebObjects) 15, 41, 44 database
Apache API 44 access to 20–21
Apple documentation 10 maintenance tools 87
applet 56, 73 modifying 21
application object 41 synchronizing Java Client data 69
application process 44 tasks 20
attribute database table
editing 52 mapping to enterprise object class 29–31
database-to-objects mapping 49
database-to-objects mapping. See model
developer documentation 11–12
B Direct to Java Client 20, 62
Direct to Java Client application 77–83
batch 51 advantages of 82, 85–90
bindings file 38, 42 architecture of 78
business logic 25 combining with HTML-based approach 88
in enterprise object 34 components of 79
implementing 34–36 creating 80–82
separating from interface code 41 disadvantages of 85–90
business object 21 guidelines for choosing 83
limitations of 82–83
subclassing classes of 82
Direct to Java Client Assistant 80
C Direct to Web 19–20
client code 86 reusable components of 41
Client JDBC architecture 71 Direct to Web application 49–62
client-server communication 17, 67, 75 advantages of 60, 85–90
code file 38–39 combining with WebObjects 89
Common Gateway Interface (CGI) 16, 44 configuring 56
component 21, 37–42 customizing 59
See also page developing 57–59
creating 45 disadvantages of 85–90
editing of 38, 46 dynamically generated pages of 50
persistence of 41 fixed sructure of 55
reusable 40–41, 62, 85 guidelines for choosing 62
separating 38 limitations of 61–62
task-specific 20 modifying single page of 60
Controller object 28 overview 49

95
© Apple Computer, Inc. May 2001
 INDEX

Direct to Web application (continued) I

reusable components of 62
rules 59 inspect page 52
Direct to Web Assistant 56–60 Interface Builder 73–74
Direct to Web template 55, 60 internal application 88
dynamic element 37, 39–40, 46 Internet Server API (ISAPI) 44
dynamic HTML publishing 13–16 intranet application 62
dynamically generated user interface 77–78

J
E
Java Client 17, 62
Edit button 52 user interface of 20
edit page 53 Java Client application 16–18, 65–76
edit-relationship page 53 advantages of 75, 85–90
enterprise object 25–36, 41–42 applets 73
advantages of 34–36 as application or applet 76
in batch 51 architecture of 66–71
configuring on list page 52 combining with HTML-based approach 88
designing for Java Client 73 creating user interface of 73–74
entity of 55 data flow in 69–70
extensibility of 26 database access 67
mapping to database table 29–31 designing enterprise objects for 73
overview 25–26 developing 72–74
reusability of 26 disadvantages of 85–90
WebObjects support for 32–34 guidelines for choosing 76
Enterprise Objects 20 limitations of 75–76
entity 55 managing user interface of 67
entity-relationship (E-R) model 29 portability of 75
EOModeler application 29, 72, 80 security in 75
Java Foundation Classes (JFC) 16, 68
Java source file 38
Java virtual machine (JVM) 88
F, G Java virtual machine (VM) 75
JDBC 2.0 driver 21
faulting 33 JDBC three-tier architecture 72
fetching 21, 33–34
foreign key 32
freeze (a page) 60
K
key-value coding 25
H
HTTP protocol 21
HTTP server 44

96
© Apple Computer, Inc. May 2001
 INDEX

L Project Builder 22, 45, 72, 80

properties 25
list page 52 displaying 55
load balancing 22 values for 50
locking 33 prototype 62, 87
logic. See business logic Pure Java 22
login page 49
look 54–55

Q
M query page 51
query-all page 50, 51
mapping 29–31
memory usage 34
menu header 53, 60
model 27, 29 R
Model object 28
Model-View-Controller (MVC) 28 referential integrity 32
relationship
editing 53
referential integrity of 32
N request-response cycle 41
reusability 26, 28
Netscape Server API (NSAPI) 44 reusable component 40–41, 62, 85
Neutral look page 54 Rule Editor 59, 81
nib file 82 rule file 78
rules 56–57, 59, 81

O
S
object graph 67–68
on-demand locking 33 scalability 22
optimistic locking 33 security 75
server performance 22
session 41
maintaining state of 41
P SQL (Structured Query Language) 20
state management 21
page 38 static element 37
See also component static HTML publishing 14
page wrapper 60
pessimistic locking 33
portability 75
primary key 32

97
© Apple Computer, Inc. May 2001
 INDEX

T overview 13–23
processes of 43
task 20, 60 server 22
task pages 55 sessions of 41
template 20 WebObjects Builder 38, 46–47, 60
template file 38–39, 46 WebObjects framework 44
transaction management 33 WebObjects look page 55
WOExtensions Framework 41

U
uniquing 33
URL (Uniform Resource Locator) 14
user interface 20
dynamically generated 77–78
requirements of 86–87

V
validation 32
variable 41, 46
View object 28

W, X, Y, Z
Web browser 43, 88
Web server 67
Web-enabled client-server application 16–18
WebObjects adaptor 15, 41, 44
WebObjects additional resources 10–12
WebObjects application 37–48
advantages of 20–23, 85–90
application object of 41
application process of 44
architecture of 43–44
combining with Direct to Web 89
combining with Java Client 88
developing 44–47
disadvantages of 85–90
HTML-based 16–17, 62
instances of 22

98
© Apple Computer, Inc. May 2001