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

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

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

Chuck Cavaness

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








3.2 Looking at the Big Picture


Now that we have described the example application that will be the
basis of this chapter's discussion,
it's time to start looking at how we can implement
it using the Struts framework. Although Chapter 1 discussed the MVC pattern in the order of
model, view, and then controller, it doesn't
necessarily make sense to follow that order as we explore the Struts
components. In fact, it's more logical to cover the
components in the order in which the Struts framework uses them to
process a request. Thus, we'll discuss the
components that make up the controller portion of the framework
first.


3.2.1 The Struts Component Packages


The Struts framework is made up of approximately 300 Java classes,
divided into 8 core
packages
("approximately" is an appropriate
term because the framework is continuously growing and being shaped).
In this chapter, we'll focus on only the top- level
packages. Figure 3-4 shows the top-level packages
and their dependencies within the framework.


Figure 3-4. The eight top-level packages in the Struts framework


The validator package
shown in Figure 3-4 does not represent the entire
set of classes and interfaces necessary for the
Validator framework. These are only
the Struts-specific extensions necessary to use the Validator
framework with Struts. There is also a ninth top-level package named
config, which consists of a single Java class.
We'll ignore this package for now;
it's not relevant to the discussion in this chapter.

The framework components are not arranged by what role they play in
the MVC patternactually, they are arranged a little
haphazardly. You might have noticed this by some of the circular
dependencies shown in Figure 3-4. This has more to
do with how fast the framework has evolved than with poor decisions
made by the designers. For example, the action
package contains some classes for the controller, some that are used
by the view domain, and even a few that probably would have been
better off in the util package. While this may be
confusing at first, you'll eventually become
accustomed to where everything is. Table 3-1
enumerates the top-level packages and provides brief descriptions of
their purposes. A few of these top-level packages also contain
subpackages, which will be covered in later chapters.

Table 3-1. Top-level packages in the Struts framework

Package name


Description


action


Contains the controller classes, the ActionForm, ActionMessages, and
several other required framework components.


actions


Contains the "out-of-box"
Action classes, such as
DispatchAction, that can be used or extended by
your application.


config


Includes the configuration classes that are in-memory representations
of the Struts configuration file.


taglib


Contains the tag handler classes for the Struts tag libraries.


tiles


Contains the classes used by the Tiles framework.


upload


Includes classes used for uploading and downloading files from the
local filesystem, using a browser.


util


Contains general-purpose utility classes used by the entire framework.


validator


Contains the Struts-specific extension classes used by Struts when
deploying the validator. The actual Validator classes and interfaces
are in the commons package, separate from Struts.

Now that you have a feel for the packages that are contained within
the framework, it's time to look at the layers in
the Struts architecture.


    / 181