Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

7.1 What Is a View?

In a general sense, a
view
represents a display of the domain model in a user interface. There
can be many different views of the same model. As discussed in Chapter 5, the domain model contains the business
entities, which hold the state for the application. Metaphorically
speaking, a view is a window that clients can use to look at the
state of the model, and the perspective may be different depending on
which window a client looks through. For example, in the Storefront
application, the front page shows a set of featured items in the
catalog. It doesn't show all of the information
about each item, only a small portion. This
"summary" view is used in the
Storefront application wherever real estate is scarce, such as on the
main page (shown in Figure 7-1).

Figure 7-1. The Storefront main page is one perspective of the model

When a user selects one of the items for sale, all of the item
details are displayed. The user is still looking at the same business
model, but the view is different. This alternate view of the model is
shown in Figure 7-2.

Figure 7-2. An alternate view of the Storefront model

A more detailed view of the business model is necessary for this
pagethere may be different JSP pages, images, multimedia
files, and other view-related components. These two different
perspectives are in fact two different views of the same model.

Because business objects don't have a natural way of
representing themselves externally, it's up to the
view components to present the domain model information to the
clients. This presentation may be in the form of XML and XSLT, SOAP
messages returned to a web service client, or, in the case of the
Storefront application, HTML rendered in a browser. A different type
of client, such as a wireless device, could look at a completely
different set of views but still use the same model. The model is
used to represent the state of the application, while the views are
used to present the model, or a portion of it, to the client.

Although the Storefront demo is a B2C application,
it's possible to have a B2B application use the same
model to make part-ordering functionality available to partners. As
long as the proper separation is maintained between the model and the
presentation layer, you can build any number of views for any number
of clients on top of the same domain model.

7.1.1 Using Views Within the Struts Framework

Generally speaking, the
views in the Struts framework are built using JSP pages. Other
approaches and frameworks are available for performing the same
functions, but JSP is the most widely used presentation technology in
the Struts community. Additional components that can be used by or in
conjunction with JSP pages to render the views include:

• HTML documents

• JSP custom tag libraries

• JavaScript and stylesheets

• Multimedia files

• Message resource bundles

• ActionForm classes

7.1.1.1 HTML documents

Although HTML documents generate only static content,
there's nothing wrong with using standard HTML
documents within your Struts applications. Obviously, they will be
unable to render any dynamic data, but they still are valid to use
whenever the view is static and you don't need the
dynamic capabilities of JSP.

For example, a login page may just be an ordinary HTML document that
invokes a Struts login action. However, to take advantage of many of
the automatic features of the Struts framework, especially ones
related to custom tags, you will need to use JSP instead of straight
HTML.

7.1.1.2 JSP custom tags

JSP custom tags can play an important role within a Struts
application. Although applications are not required to use them, some
scenarios would be difficult to program without them. Future versions
of the framework should make it easier to use alternate technologies,
but custom tags likely will maintain their importance.

7.1.1.3 JavaScript and stylesheets

The Struts framework doesn't prevent you from using
JavaScript within an application. On the contrary, it provides
functionality within the tag libraries to facilitate using
JavaScript. JavaScript support within custom tags is discussed in
Chapter 8.

The Struts framework does not prevent you from using stylesheets,
either. You can include stylesheets in a JSP page, and they will be
rendered in the browser just as standard HTML pages would be.

Stylesheets are used to help web designers gain more control over the
appearance of a web site. Features such as character size, color,
font, and other look-and-feel characteristics can be changed in a
central location and have an immediate effect throughout the entire
site.

7.1.1.4 Multimedia files

Multimedia files are used in just about every web application. These
include but are not limited to:

• Images (.gif, .jpg, etc.)

• Audio (.wav, .mp3, etc.)

• Video (.avi, .mpg, etc.)

Images probably are the most widely used, although for B2B
applications, audio and video files also are prevalent (e.g., for
displaying CAD drawings and specifications). The Struts framework
supports using multimedia files within an application. This support
is achieved mainly through the use of custom tags, but you can also
use standard HTML to render these types of resources.

There are a few sore spots when it comes to rendering images using custom tags. Differences between absolute and relative paths can cause some images not to display properly. The best advice is to decide whether you are going to need relative or absolute paths and then be as consistent as possible.

7.1.1.5 Message resource bundles

Message resource bundles, commonly referred to simply as resource
bundles, are a very important component for Struts applications. They
provide a means to support
localization
and also help to reduce maintenance time and redundancy throughout an
application.

For example, suppose your web application uses certain text labels or
messages in multiple locations. Instead of hardcoding the string in
every page, you can specify it in the bundle and retrieve it using
one of the custom tags. Then, if the text label or message needs to
change, you need to modify it only in one location. This helps to
reduce maintenance time.

Some developers consider the resource bundles as belonging to the model, rather than the view. This is because application data (in the form of messages) is stored within the bundles. However, because the bundles also contain labels and strings for such things as text fields, checkbox labels, page titles, and so on, a valid argument can be made either way.

7.1.2 Using JavaBeans Within the View Components

It might seem weird to talk about JavaBeans within a
chapter on views. However, because JavaBeans make up a large portion
of how the model data is used within the framework, it makes sense to
discuss them briefly.

7.1.2.1 Quick refresher

JavaBeans
itself is a portable, platform-independent component model written in
the Java programming language. The JavaBeans component architecture
allows developers to create reusable components that can be used on
any platform that supports a JVM. The JavaBeans model supports
properties, events, methods, and persistence.

The Struts framework (and Java web applications in general) uses only
a small portion of the capabilities defined in the JavaBeans
specification. JavaBeans in Struts applications are used like
ordinary Java objects, but they must follow certain guidelines:

• Must provide a zero-argument constructor.

• Should provide both a get<PropertyName> and
  set<PropertyName> method for all properties
  defined within the bean.

• For Boolean properties, if the method
  is<PropertyName> is present, it will be used
  to return the property value.

• For indexed properties where a property like
  <PropertyElement>[] is defined, the
  following methods should be present:
  get<PropertyName>(int a)
  and set<PropertyName>(int a,
  PropertyElement b).

These guidelines are necessary for the beans to be introspected at
runtime by the framework.

One of the common traps that Struts developers fall into when dealing with JavaBeans is to use a return type that's different from the parameter type. If you create a method in a JavaBean that passes a String as an argument: public void setDescription( String newDescription ); you must have a corresponding get method that returns the same type: public String getDescription( ); If the return type differs from the parameter type, the Struts framework may not recognize it as a bean, and you likely will get an error message stating that "No getter method could be found" or "No setter method could be found" for the property name.

7.1.2.2 How Struts applications use JavaBeans

In a strict MVC
architecture, as shown in Figure 7-3, the view gets
updates directly from the model when it receives a notification that
something has changed within the model. With web applications, this
notification is not possible, or at least is difficult to achieve.
Normally, it's up to the client to issue a request
to the controller to refresh a view from the model state. In other
words, the client "pulls" the view
from the model, instead of the model
"pushing" changes out to the view.

Figure 7-3. The view queries the model for state information

7.1.2.3 The Data Transfer Object pattern

Chapter 6 discussed one approach to building
the model components for a Struts application. The one thing that was
intentionally left out was exactly how the view accesses the data
from the model. To understand this, it will help to understand the
Data
Transfer Object (DTO) pattern (sometimes referred to as
the Value Object or Replicate Object
pattern).

The DTO pattern is used quite frequently in J2EE applications, where
distributed components making remote calls can suffer serious
performance setbacks from using too many remote invocations. It is
used in other technologies as well, under different names and guises.

A DTO is a coarse-grained view of what is typically fine-grained
information. It aggregates various attributes from one or more
business entities and puts this information into a JavaBean instance.
This instance can then be passed throughout the local application, or
even be serialized and sent over the network, and clients can
retrieve the model information from a local object without suffering
any negative performance impact.

The DTO normally doesn't provide any business logic
or validation; it just provides access to the properties of the bean.
Some documentation on this pattern suggests that the bean should be
immutable, to help reinforce that the object is local and that
changes will not be reflected in the system. However, this can cause
problems because the JavaBeans specification requires that all
private properties have get<PropertyName>
and set<PropertyName> methods. It is up to
you to determine how best to handle the mutability of DTOs based on
your requirements.

DTOs effectively are part of the modelthey are just local,
possibly immutable copies of the business objects. Within Struts
applications, they are used by the view to deliver the model data
that is rendered along with the static information in the
page.