|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Class Summary | |
ScopeServlet | Base class for a web app's servlet dispatcher: subclass this to implement application startup and initialisation (use a static initializer). |
ServletContext |
A ViewContext that handles
showView(), hideView() and showError() for servlet implementations. |
A servlet implementation that provides a simple implementation of the HMVC pattern for HTTP request handling. It provides a single servlet that handles despatch of Controls into the chain of responsiblity and can optionally repopulate Models with values sent in the HTTP request (two-way data binding).
Incoming requests for a web application are sent to
ScopeServlet
or (more likely) a subclass of it that specialises certain functionality.
The servlet uses a form parameter to determine which View the user
interacted with (view=foo
).
This View will issue a Control into the chain of responsibility via its Controller.
The Control to describe the user's interaction is constructed from
a form parameter (action=bar
). The Control's parameter
is a HashMap containing the form parameters left after stripping the
automatic model repopulation parameters described below.
Form parameters with a '.' prefix are treated by
the active View as instructions to repopulate
the Model: the parameter key is stripped of the '.' prefix
and treated as a property description.
eg the form parameter
.name=Fred
will populate the "name" property
of the model bound to a View.
The doPost method is implemented as follows:
A number of basic consequences follow from the current implementation of ScopeServlet and the accompanying ServletView classes. In part this is due to the adoption of MVC strategies that are well proven in the environment of rich desktop GUI implementations.
Controllers throughout Scope are arranged in a tree hierarchy with more "global" Controllers parenting more specific ones. This enforces a one-way dependency from a parent to the children it creates to handle specific areas of functionality.
In a servlet, the top-most Controller is the root of the application. This should provide application-level Control handling and one-stop application initialisation which will probably involve creating child Controllers to handle related sets of functionality.
The entire structure might be similar to this:
A Controller is able to redirect the flow by constructing a HashMap
of form parameters for the new request then calling
ScopeServlet.redirect(java.util.HashMap)
.
ScopeServlet.doPost(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
by calling
ServletContext.showError(java.lang.String, java.lang.String)
.
The default showError implementation is
very simple and will need to be overridden in real applications. To do this,
override showError in a subclass of ServletContext, then override
createServletContext in a subclass of ScopeServlet to return an
instance of your new ServletContext subclass.
In practice, it has been found useful to consider the state changes allowed as the user navigates between Views. This factor has emerged as crucial in building web applications in which users can change application flow by using the browser's "back" button or bookmark feature, in which case it becomes necessary to cope with unexpected changes in state. State management for web applications can be bolted into a Scope application by hooking into the ScopeServlet class. No implementations are known to date, though some work has been considered in line with the work described in this paper: Server-side MVC Architecture An implementation of this strategy is currently under way at: Java State Machine and this may prove to be a fruitful project to investigate further.
|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |