Z
zhanggok
Unregistered / Unconfirmed
GUEST, unregistred user!
First, let it be said that, for the most part, the Struts ActionServlet components canbe used as they are. Theydo
not need to be subclassed (but can be), and thedefault classes get the jobdo
ne with a minimum of fuss. From an architecturalperspective, the Struts ActionServlet is a blackbox component [Johnson].
Throughout this book, we have often referred to the Struts controller servlet
and described how it fits in with the various components that make up the Struts framework. This jibes well with actual practice, since to work with Struts on a dayto-day basis, most developers only need to know how the ActionServlet interacts with the other components they use. Struts developers, rarely, if ever, work with the ActionServlet directly.
The implementation of the ActionServlet changed quite a bit between
Struts 1.0 and Struts 1.1—so much so, that we will cover only the
Struts 1.1 ActionServlet here. Most developers did not subclass the Struts
1.0 ActionServlet, or did so in very minor ways. Moreover, the ActionServlet
is designed as a singleton. At most, applications will subclass Action-
Servlet exactly once. Since Struts developersdo
not work with the
ActionServlet on a day-to-day basis, we will not contrast the differences
between the releases, as we havedo
ne else
where. By simply describing
the ActionServlet as it now stands, if necessary, Struts 1.0 developers will
be able to adapt any changes they might have made.
There are two key reasons why Struts developers are so detached from the Action-Servlet. First, it is a true singleton. There is exactly one ActionServlet present in any Struts application. Wedo
not create new ActionServlets the way we create new Actions or ActionForms. In Struts, there is simply not much development work left todo
with a servlet.
Second, the ActionServlet spends most of its time invoking other objects.
Rather than code to the servlet, we code to the objects the servlet calls. Many frameworks use this approach. In fact, it is considered a formal design pattern, Inversion of Control [Johnson]. The ActionServlet coordinates the application’s activities, but the methods defined by the user to tailor the framework are only called by the servlet. They are not declared within the servlet.
not need to be subclassed (but can be), and thedefault classes get the jobdo
ne with a minimum of fuss. From an architecturalperspective, the Struts ActionServlet is a blackbox component [Johnson].
Throughout this book, we have often referred to the Struts controller servlet
and described how it fits in with the various components that make up the Struts framework. This jibes well with actual practice, since to work with Struts on a dayto-day basis, most developers only need to know how the ActionServlet interacts with the other components they use. Struts developers, rarely, if ever, work with the ActionServlet directly.
The implementation of the ActionServlet changed quite a bit between
Struts 1.0 and Struts 1.1—so much so, that we will cover only the
Struts 1.1 ActionServlet here. Most developers did not subclass the Struts
1.0 ActionServlet, or did so in very minor ways. Moreover, the ActionServlet
is designed as a singleton. At most, applications will subclass Action-
Servlet exactly once. Since Struts developersdo
not work with the
ActionServlet on a day-to-day basis, we will not contrast the differences
between the releases, as we havedo
ne else
where. By simply describing
the ActionServlet as it now stands, if necessary, Struts 1.0 developers will
be able to adapt any changes they might have made.
There are two key reasons why Struts developers are so detached from the Action-Servlet. First, it is a true singleton. There is exactly one ActionServlet present in any Struts application. Wedo
not create new ActionServlets the way we create new Actions or ActionForms. In Struts, there is simply not much development work left todo
with a servlet.
Second, the ActionServlet spends most of its time invoking other objects.
Rather than code to the servlet, we code to the objects the servlet calls. Many frameworks use this approach. In fact, it is considered a formal design pattern, Inversion of Control [Johnson]. The ActionServlet coordinates the application’s activities, but the methods defined by the user to tailor the framework are only called by the servlet. They are not declared within the servlet.