Import event-driven technology in jsp-servlet development

Js|servlet Jsp-servlet provides an excellent platform for Web application developers. However, most of the domestic development based on Jsp-servlet is in the most basic state, code reuse rate is low, low development efficiency, can not adapt to large-scale, complex web development requirements.

First, to implement event-driven, MVC technology must be used in jsp-servlet development.

M=model (model)
V=view (view)
C=control (Control)

View (V) defines the user interface. The model (M) defines abstract classes and logic. Control (C) is responsible for doing business processing based on the logic of the event invocation model that occurs in the view.

So so

Model is implemented by ordinary Java classes.

The view is implemented by the JSP.

Control is implemented by the servlet.

Views and models are closely related and independent of each other.

A model is an abstraction of a view and must contain some logic to handle the events of the objects represented by the view.

At the same time, views can be expressed in a variety of ways for the same logic.

For example, in web development,

[1] For a singleselection class that represents a "radio" abstraction, it can be displayed as a radio button on the user's browser, a radio drop-down box, or any other control of a single selection nature.

[2] for a submition class that represents a "submit" abstraction, it can be displayed as a Submit button on a user's browser, a hyperlink, a picture, or even any control that triggers a JavaScript-capable submit () method.

Event-driven is extremely important for MVC technology and is implemented primarily by control. The Jsp-servlet implementation itself is ideal for writing event-driven programs.

As we all know, the Javax.servlet.http.HttpServlet class calls every

DoPost (httpservletrequest req, HttpServletResponse resp)

Or

Doget (httpservletrequest req, HttpServletResponse resp)

method to respond to a client's submit operation.

The event that the servlet responds to is the client browser's submit operation. The client browser's submit event triggers a specific event-handling method for the servlet, but there is only one entry: the service of the Javax.servlet.http.HttpServlet class (HttpServletRequest req, HttpServletResponse resp) method. (Specific to the response to the operation of the client, it may be dopost (httpservletrequest req, HttpServletResponse resp) or doget (HttpServletRequest req, HttpServletResponse resp) method.

So you can override these methods to control how the servlet responds to a submit event, calling a different Jsp,java BEAN, or even an EJB.

Example: Eventdrivenservlet inherits Javax.servlet.http.HttpServlet, and overrides Dopost (HttpServletRequest req, HttpServletResponse resp) and Doget (HttpServletRequest req, HttpServletResponse resp) method, so that all 2 methods directly call the same method, we named this method "Act"??

void Act (httpservletrequest req, HttpServletResponse resp)

The Act method should call the corresponding class and method based on the information passed in by the Req parameter, and finally return the RESP to the client.

The Act method processing must include the following points:

1) Analytic req.

2 Initialize (or update) the corresponding class according to the analytic result of the previous step.

3) Call the corresponding method for logical processing.

4) The processing results are reflected in the RESP.

5 Specifies the next displayed page according to the logical processing result

6) forward to the next page.

However, how does the act approach know which method of calling which class to call, and which image to migrate to?

The answer is to pass to the Act method a message?? Message.

The message class is an abstraction of the messages, which should be defined as abstract, and can be an empty class. Derive all of the specific message classes from this messages class. All messaging classes must inherit from the message class.

As I said before, each of the controls that can be submit on the screen (JSP) logically corresponds to a submition, and each submition is associated with a particular message class. That way, as long as we can intercept these message classes at the control layer, and parse the information that these message classes carry, and delegate them to the appropriate class method, we can implement event-driven.

Cases:

There is a "login" button on the screen that corresponds to a submition class and produces a loginmessage message. Loginmessage inherits the message and adds a Hashtable member variable that carries information about the username and password.

A "Change Password" button is also on the screen, which corresponds to a changepasswordsubmition class and produces a changepasswordmessage message. Changepasswordmessage inherits the message and adds a Hashtable member variable that carries information about the username and password.

When the servlet responds to this submit, it can delegate processing based on the type of message and the information it carries.

When implemented, we should overload the Eventdrivenservlet Act () method and add an argument to the message class.

void Act (httpservletrequest req, httpservletresponse resp,message message)

If the message instanceof Loginmessage is true, it is styled as a loginmessage, and the loginmessage is passed to the appropriate method, and the corresponding screen is specified and returned to the client after the processing is completed.

If the message instanceof Changepasswordmessage is true, the message is styled as Changepasswordmessage, and passes the changepasswordmessage to the corresponding method, after processing completes assigns the corresponding picture and returns to the client.