Author Homepage: Programming Compass
About the author: High-quality creator in the Java field, CSDN blog expert, invited author of Nuggets, many years of architect design experience, resident lecturer in Tencent Classroom
Main content: Java project, graduation design, resume template, learning materials, interview question bank, technical mutual assistance
Favorites, likes, don't get lost, it's good to follow the author
Get the source code at the end of the article
Note: If you need to ask for the original English document, please check it at the end of the article after three links
MVC architecture drives refactoring to realize client web page composition
- introduce
In a web application, web pages typically share content like headers, footers, and menus. Templates are used to maintain this common content in one place and they are separate from page specific content. Template-based web applications (TWA uses such templates to dynamically generate web pages, combining page-specific content with templates. For example, in Figure 1, three pages are generated using a template and each page's details.
TW basically interacts with the user, using the mUlti page application model, when a user makes a request, a web browser downloads and displays a new page. As shown in Figure 2a, one of the most important things about TWA is that the server combines and sends templates together and uses page-specific content on each request. Therefore, the template is transmitted redundantly and rendered with a full page refresh on each request.
One solution to the above duplicate problem is to move page composition from the server to the browser. Whenever a user clicks a hyperlink or submits a form, the web browser receives the difference between the current page and the new page, and then partially updates the current page with the difference, without a full page refresh. As shown in Figure 2b, each request ReqI/ and Req2/ uses a partial page refresh with its associated difference. Page PI is actually a page but can have a different Uniform Resource Locator (URL), depending on its status (ie, the content it contains). Such web applications are known as Single Page Applications (SPA).
Figure 1. Template-based web applications In Java web applications, the <jsp:include> standard action is often used to populate the template's placeholders with page-specific content.
Figure 2. Web page composition
Model-View-Controller (MVC) architecture is commonly used in web application development. Therefore, it is natural to consider the three components and their interactions as the basic unit of analysis and modification when reorganizing or redesigning a multi-page application into a single-page application. However, these architectural components have transformational issues that have not been adequately discussed in most previous works.
A transformation basically requires its prerequisites to be satisfied before it can be executed. In particular, reduced duplication of code/data can sometimes lead to inconsistencies between source and target applications: the observable behavior of the target application may differ from that of the source application. However, most previous research on transformational problems does not specify situations where transformational methods cannot be applied.
Therefore, it is necessary to specify the prerequisites for the transformation steps in terms of building components of the MVC pattern. This paper proposes a method to decide whether a given full page request can be refactored into a partial page request without changing the observable behavior of the source application from the application point of view of the MVC architecture. A reconstruction algorithm is also proposed to describe the reorganization steps and recombination premises. We present the overall picture of reorganization to treat the execution of an algorithm as an activity. Additionally, the paper describes important problems we encountered when implementing the reorganization algorithm. Furthermore, we present case study results showing that when our tools are used, the effort required for reorganization is reduced and the performance of web applications is improved.
2. Question and background
The reorganization issues addressed in this paper can take into account that the low-level reorganization of the user interface (UI) structure, page navigation model (i.e. links between web pages), data model and functional source applications do not change. The destination application has the same look and feel as its source application, but it improves response time and performance by the amount of data transferred over the network and provides asynchronous communication capabilities between the server and the browser. Furthermore, the coupling between template and page-specific content reduces content through reorganization, so maintenance (eg, adding new page-specific content for new requirements) can be performed more easily. The rationale for choosing low-level reorganization is to seamlessly refactor the input application's multi-page architecture into a single-page architecture without confusing users. We assume that the input TW As is using the Java Server Pages (JSP) Model 2 architecture which adopts the MVC pattern. This assumption is reasonable since the JSP Model 2 architecture was mentioned in the JSP early specification of JSP and gained wide acceptance in the industry.
There are many approaches to restructuring the problem or redesigning a multi-page application as a SPA. However, it's hard to find a perspective on the MVC pattern, which is a popular architectural pattern for web application development, that addresses this issue. An earlier version of this article explicitly considered models, views, controllers and their modification interactions. However, previous studies have some limitations. The premise of reorganization is not description. No algorithm is shown for performing the reorganization automatically, so implementing this method is not easy. Experimental results are not shown for the recombination process.
In this paper, we improve on previous research and propose an algorithm that considers reorganization of input-output consistency checks between applications from the perspective of the MVC pattern. Furthermore, we present the results of the case study in terms of process quality.
This subsection succinctly describes the clarity of our previous work to help people understand more about this paper. A Java web application basically consists of JSP, servlet and JavaBean objects which are mapped to view, controller and model respectively from the perspective of MVC architecture. Web templates have been used to provide users with a consistent view and reduce code in web applications. This template creates and manages shared components such as menus. When a user makes a request for a page, the request is sent to a servlet, which executes its business logic. The results of the execution are then included in the template to generate the page sent to the browser. Access to JavaBeans objects to manipulate business data is performed by servlets and views during request processing. picture. Figure 3a shows the dynamic architecture for handling user requests.
The architecture has a problem with templates downloading and rendering each user's full page refresh request. Therefore, our previous work proposed a method to reorganize TWA into client-side webpage composition to solve the problem. The main idea is to download the template the first time the application is accessed, and then, if possible, bypass downloading the template on subsequent visits. Additionally, user requests are converted from normal Hypertext Transfer Protocol (HTTP) requests to Asynchronous JavaScript and XML (AJAX) requests in the browser to enable partial updates. Complete pages are written in the browser with the help of JavaScript code that updates the current Document Object Model (DOM) tree and replaces the old page-specific parts with the downloaded ones. Figure 3b shows the dynamic architecture for handling user requests. Therefore, the output application is SPA.
Our previous work also supports backward navigation and bookmarking functionality to enable access to reorganized applications in the same way as classic web applications. When the user clicks the back button of the browser in the SPA, the browser will not return to the previous state SPA by default, but visit the page visited before the SPA (see Figure 4a). To address the problem, our previous work applied the Hypertext Markup Language 5 (HTML5) History API, which stores the current state of the browser history stack upon user request and retrieves instructions when the back button is used (see Figure 4b). SPAs have different states, but by default there is only one URL. Therefore, our previous work also proposed a method of assigning a unique request URL for each state for bookmarking and revisiting the state.
3. Reorganize template-based application INTO single-page application
- reorganization process
In this subsection, we present our overall restructuring process to modify TWA into SPA (see Figure 5). These steps are briefly described below.
First, the engineer implements and understands the source
View the application from the user's point of view. She then gathers links and forms that can be reassembled by issuing normal HTTP requests. For each request, engineers can extract a dynamic architecture that can be represented as a collaboration diagram similar to the diagram in Figure 3a showing the collaboration between Web components. The architecture can be effectively used for reorganized verification step applications. Extraction of schema can be achieved using filter and wrapper component development techniques provided in Java Web. The extraction steps are not described in detail due to limited space. Now, the engineer understands the functional and architectural application of the source, and thus executes a refactoring algorithm to restructure the input application into an SPA. Verify that the output application is fmished after reorganization. Manual conversions can be performed when problems are found, including missed and incorrect conversions.
Note that this article focuses on this architectural transformation and its supporting tools. Therefore, we have developed an Eclipse plug-in to support the "execute reorganization" algorithm" step, described in the following section in detail.
Figure 3. Architectural Transformation of Client Web Formation
Figure 4. The backward navigation problem and the solution by Oh et al.
Figure 5. Overall reorganization process
- reconstruction algorithm
First, the TWA is parsed to collect a list of full-page requests, then each request is analyzed if possible, modified for partial-page requests by using transformRequestO (see lines 1-15). If the transformed request brings the resulting SPA into an inconsistent state, i.e. the original state request is not transformed (see lines 5-7). Therefore, the output application can be a multi-page application, where each page runs as a single-page application. This inconsistent state can arise in three cases from an MVC perspective architecture.
The first case is when the transformed request generates a view that does not exist in TWA (see line 20). For example, suppose we have a full page request that changes the current template as well as page specific content. If r is transformed to download new partial page requests for page-specific content, the transformed request will produce an inconsistent view.
Template is not a static page, but a dynamic page. Different template objects instantiate classes from templates, depending on system/user state. For example, in the figure, the template object is replaced after the user logs in because their menu is different. When a user request requires a new template instance, the SPA should also download the new instance. One of the possible designs is to download the difference between the old template object and the new template object. However, these differences can be scattered throughout the world template objects, so it's not easy to implement. Therefore, we made the decision not to convert the original full page request.
The second case is when a transform request for the original image results in an inappropriate situation: 1) an invalid controller is introduced into the SPA, or 2) a request is made to a different controller than we expected in TWA (see lines 21-23 ).
First, web browsers execute client-side code in HTML, Cascading Style Sheets (CSS), and JavaScript. Among them, the JavaScript code plays the role of the client controller. One of the important things about client-side code is that when page-specific content is replaced, its side effect is to execute JavaScript code from the old page-specific content, unlike HTML and CSS code. On the other hand, a full page request will unload all client code from the old page. Therefore, analysis is required to determine if outdated JavaScript code is making SPAs behave differently than TWAs. A TWA for a specific scenario that changes observable behavior is as follows: For example, suppose a page-specific TWA in which part of a page has JavaScript code that downloads an image page whenever the user scrolls to the bottom (e.g., via window.onScrollO event handling in an AJAX request program) to reduce page load time. If the user moves to a new physical page, such event handling code is automatically removed due to page unloading. However, in a restructured SPA, code being removed doesn't happen automatically, because entering a new state doesn't cause a full page refresh. This means that an invalid controller exists in the SPA (line 21).
Second, the SPA should preserve the page navigation model (including back/forward navigation and refresh) imported into TWA. For example, suppose TWA's page PI is restructured into SPA page p", so that Ps is the same as PI and both pages are refreshed, and the new page should also be the same. To achieve this, each state of SPA has a unique URL, For example, every page of TWA. The URL of this state needs to contain information used to identify the state (for example, requesting the URL to get its page-specific content). Therefore, when a page is refreshed, the page-specific content can be obtained together with the template (see Figure 8). There is one important thing to note when refactoring a full page request into a partial page request using AJAX: when the initial request is redirected (via a redirection from the server to the HTTP request by the web browser) to Another component c, the redirected URL (i.e., the requested URL of c), cannot pass through SPA by default. On the other hand, the redirected URL is displayed in the address bar of a web browser with TWA. Therefore, when we Attempt to refresh the page of the SPA, which includes an HTTP redirection request as page-specific content, the SPA behaves differently than it entered the TWA. This means that the SPA sent the request to the inappropriate controller (lines 22-23).
The third case is where a transformation request can be generated for a model that does not exist in TWA (see line 24). For instance, the transformation of the original request to continuously update the server state can allow generating SPAs with invalid data. A more specific situation is as follows: Suppose in TWA we have a page that cannot submit a payment form with the same data more than once. However, if its transformed form allows the same data to be submitted twice, the transformation disadvantageously incurs double payments, which is an example of the double submission problem.