Shulou(Shulou.com)06/03 Report--

1.1 Concepts and premises

To understand this section and learn to use state mode to develop Portlet, you must have several of the design ideas mentioned here and basic Java development skills. The development tools we have chosen here are IBM Rational Application Developer and Portlet Toolkit. You need to be familiar with this tool and know how to create packages, classes, pages, and .jar for Portlet and Portlet.

1.1.1 State mode is applied to Portlet

StateManagerPortlet is the main Portlet class and is Portlet independent. It is used as a dispatcher to support operations and state classes that host Portlet code, and Portlet-specific controller code exists in this class. A class that extends the Action abstract class implements the actionPerformed method, which performs any controller functions necessary to implement a specific operation request behavior.

The class that implements the state interface implements a performView method, which is called by the service method of StateManagerPortlet. The method also contains code that typically resides in these methods. Again, this code is specific to the state class in which it resides, thus avoiding any additional control logic confusion caused by determining the requested operation.

Applying the state pattern makes the implementation concise. Moreover, when switching between the various modes of Portlet, the state is always remembered. With this pattern, you can easily determine when and where you want to retrieve data from the source, and when you should retrieve data from the cache. Because the actionPerformed method is not called when the portal page is refreshed, the data access code can be placed in the operation state and cached there. The state class can use the data in the cache to avoid accessing the data multiple times when refreshing the portal page.

1.1.2 Why does Portlet use state mode

Considering the simple MVC-based Portlet, it copies the XML file containing a list of product download configuration parameters from the remote machine to the local (host where the Portal system is located), retrieves the parameters, and presents the list to the user. After the user selects an item, a detailed view is displayed, which shows the details of the selected item. This detailed view may involve making another request to the database. Users with editing rights can enter the editing mode of Portlet to view and modify the contents of the XML file. After saving, if you find that the XML file has been modified, it will be sent back to the remote machine; otherwise, the file package will still be stored locally in Portal to avoid occupying system resources.

As a first step, the controller must invoke the business object to create the appropriate Bean, which is passed to the JSP for display in the main view. In the second step, the controller retrieves the indicator of the selected item in the user's request, and then invokes the business object to create an appropriate Bean, which Bean is passed to different JSP for display in the detail view.

In the MVC implementation, the view components are obviously different. These two views require two different JSP. You may need to access different business model components to generate the Bean required for each request. The controller function needs to know:

-which business methods are called?

-which Bean are generated?

-where do I put the Bean on these request objects?

-how to call the appropriate JSP?

This is where the code gets complicated. If you are programming with Servlet, you may choose to implement them as different Servlet so that the service methods of each appropriate Servlet class naturally separate the controller functions of each request. If you prefer to use a dispatcher approach rather than a different Servlet implementation, you must use a framework (such as Struts) to implement a similar MVC design.

This is a complex task because you cannot choose to use multiple Portlet classes to implement a Portlet, and you cannot deal with the Portlet class directly. The same Portlet service method is used to handle all HTTP requests returned to the Portlet, so you need to implement the control code class with the following functionality.

-determine which action is being requested?

-what needs to be done?

-what kind of state does Portlet put in?

-what content is displayed and returned to the user?

1.2 requirements Analysis 1.2.1 Portlet functional requirements

We run an automatic download program on the Linux host test.cn.ibm.com. The list of products to be downloaded and the parameters of each product are saved under / home/isc/downLoadConfig/, and the file name is AutodownConfig.xml. We are running IBM WebSphere Portal 5.1 on the Windows 2000 Server host Netecauto01. Ordinary users can only view the product list and configuration permissions. When the user wants to view configuration information, Portlet can copy the file AutodownConfig.xml from the server to the local server, and read out the contents of the XML file and display it in the list. The user with administrative authority also has the right to modify each configuration information and can modify the parameters of the product configuration information. After the modification is completed, for the configuration to be valid, the XML file must be sent back to the directory where pvcent07 is stored.

AutoDownLoadConfig Portlet maintains an automatic download product configuration list. In edit mode, users can browse and download the product list, view the details of a selected downloaded product, or modify the configuration information of a product. In configuration mode, users can set data access information. Although the available data sources provide a complete implementation, including the configuration mode, in order to meet the design purpose, we only need to pay attention to viewing and editing the implementation of the pattern. Automatically download the Portlet status mode diagram as shown in figure 1-1.

Figure 1-1 automatically downloading schematic diagram of Portlet status mode

1.2.2 Angle Architecture Logic based on MVC Model

1. Organize the logic of Portlet based on MVC architecture.

From a visual point of view, the implementation of the scenario function shown in figure 1-1 requires at least the following page.

Main view page (Main View Page)-displays a list of all products being downloaded and options for selecting a product for more details.

-details View page (Detail View Page)-displays the configuration details of the selected product.

-main editing page (Main Edit Page)-displays a list of products that the user has permission to edit and options for modifying more information.

-modify item page (Modify Entry Page)-displays a similar form with existing data inserted for modification, including modifying individual parameters and adding or deleting a list of entries to a parameter.

In this case, the user can select the product item to be edited from the main editing page. After modification, there is no confirmation page or successfully executed page. Perform item modification processing and refresh the editor-in-chief page, and if there is an error, the appropriate message is displayed, but during normal processing, there is no view associated with the operation.

How to improve this implementation? First, keep in mind that the application represents a set of application actions and states; the second action is a class that implements the operation interface, which actually performs an application task or operation processing. This is part of the application code that currently exists in the actionPerformed method of the actionListener class, and only this part is specific to a single action event.

A state is a class that implements a state interface, which represents the effect of Portlet as a result of an operation applied. In general, this class has visual components.

What is contained in 2.Portlet

Based on the above analysis, we will have the following operations.

-Master list view of all product configuration information.

-displays the view of configuration details for the selected product.

-displays a list of edit views for all editable products.

-display the view to modify the configuration information of a product.

-add an optional download item or email to the product.

-Delete an optional download item or message for the product.

Performing these actions results in one of the following states.

-Home view.

-details view.

-main editing view.

-add download product view.

-modify the download product view.

From a visual perspective, the implementation of downloading the product list Portlet includes the following view (page).

(1) Home view (Main View)-displays a list of downloaded products with options to select downloaded products for more information.

(2) details View (Detail View)-displays the details of the selected downloaded product.

(3) main Editing View (Main Edit View)-displays a list of downloaded products with options to add, delete, and modify downloaded product information.

(4) add download product view (Add Contact View)-display the form view to enter information about the newly downloaded product.

(5) modify the download product view (Modify Contact View)-display a similar form view to add the element data of the existing downloaded product for modification.

1.3 Portlet detailed Design 1.3.1 Program flow Design

The following is an illustration of the data flow of the program.

In display mode, Portlet copies back the XML file from the remote pvcent07.cn.ibm.com to read out and display a list of all products being downloaded. Click any item in the list to display a detailed view of the item. Let's first look at the product download list, as shown in figure 1-2.

Figure 1-2 Product download list

When you click the link for any product, the specific configuration parameters for that product are displayed, as shown in figure 1-3.

Figure 1-3 specific configuration parameters of the product

In edit mode, the first display is a list of product configurations that the user has permission to edit, as shown in figure 1-4.

Figure 1-4 list of product configurations that the user has permission to edit

Click the link for any product to go to the editing interface for that product, as shown in figure 1-5.

Figure 1-5 the editing interface of the product

Users can add CD media or an E-mail to the product, as shown in figure 1-6.

Figure 1-6 adds CD media to download for the product

Of course, users can also delete the CD media or E-mail to download, as shown in figure 1-7.

Figure 1-7 Delete CD media to be downloaded

The user can modify any of the parameters, then click the "Save To XML" button, and Portlet will save the parameters to the XML file and pass them back to the pvcent machine, as shown in figure 1-8.

Figure 1-8 saves changes to the Portlet configuration file

Verify that the changes were saved successfully, as shown in figure 1-9.

Figure 1-9 confirms that the changes were saved successfully

1.3.2 overall Design of Actions and States

1.StateManagerPortlet

StateManagerPortlet is the main Portlet class, is Portlet independent, and generally includes all Portlet-specific code. This class is used as a dispatcher to support operations and status classes that host Portlet code. StateManagerPortlet implements the actionPerformed, doView, doEdit, doHelp, and doConfigure methods.

The actionPerformed method simply takes the current instance of the action class and dispatches it to its actionPerformed method. Similarly, the do method takes the current state object and dispatches it to its perform method. Therefore, StateManagerPortlet does not need to know any details of the current Portlet implementation, nor does it have a large number of if and checks to determine the next step. As long as you are familiar with the process between state and operation, the processing can be done correctly without having to write too much redundant control logic code.

2.ActionClassManager

In WebSphere Portal, the ActionClassManager method adds an instance of the Action class to the deprecated PortelURI. This API is useful because you can retrieve an instance of the Action subclass from the PortletEvent object and dispatch the instance to its actionPerformed method as part of the state transition. The recommended API will be added to the PortletURI using a string instead of Action and retrieved from the Portlet Event. The ActionClassManager class provides an instance mapping from a given string to the Action class.

-Action

The class that implements this interface will implement the actionPerformed method, which can perform any operation to implement the function required by the operation request. However, the implemented function is specific to the action event being called. The individual actionPerformed methods of an action class contain only the code for that operation, and the method also sets the current state for further processing. In this process, after the operation is called, it does work specific to its function and then sets the state for the next transition.

-InitialStateManager

This class provides the initial state for each supported Portlet mode.

-State

Generally speaking, the perform method of State will call JSP to display its results. The user interface may allow the user to set other actions in the Portlet. JSP associates the action class with each action on the page. When the user invokes one of these operations, the actionPerformed method of StateManagerPortlet invokes the appropriate instance of the action class, followed by a state transition. State classes are not responsible for state management and transition.

The class that implements this interface needs to implement the perform method, which can be called by the StateManagerPortlet's do method, which contains the code that typically resides in these methods. Again, the code is specific to the state of the class in which they reside, thus reducing complexity.

1.3.3 Code class design, operation class list

The functions of each of the classes we created are briefly described below.

Introduction to functional Logic of 1.State Class

Subclass 1:ActionClassManager class

The ActionClassManager class is responsible for returning an instance of an operation subclass that gives a class identifier that is added to the PortletURI through the addAction (string) method. We follow the convention of making the class identifier fully qualified so that we can easily create an instance of the class. However, we can avoid unnecessary object creation by dealing with the operation subclass instance separately, and then we need ActionClassManager to return a single instance for the referenced operation subclass.

Subclass 2:ActionPerformed class

An abstract operation class defines two abstract methods, so its subclasses must implement actionPerformed methods and setState methods. When the StateManagerPortlet class dispatches processing from its actionPerformed method, the actionPerformed method of the operation subclass is called.

The setState method can also be called by StateManagerPortlet to ensure that the implementation of the operation subclass sets the next state after the operation requested by the user is processed. The action class implements its own setState method, which the subclass must call to actually set the next state. This ensures that the action class and state class know in which class the next state is set and restored, without the need for subclasses to know these mechanisms. These states span HTTP requests and are maintained in each Portlet mode. Therefore, when the user changes the mode, the control returns to the state of the most recent access.

Subclass 3:MainViewAction operation class

The MainViewAction class does not require any specific operation handling. In fact, we need to display the list of downloaded products in the main view. We can implement the code to create the appropriate download product list Bean in the actionPerformed method, set the code in the session or request object, and then set the next state to MainViewState. The subclass performView implementation inherits the MainViewAction operation class and can simply call JSP and submit the list content from the session or request Bean. However, we must pay attention to portal page updates in case the MainViewState and performView methods of Portlet are called instead of the actionPerformed methods of MainViewAction. So, we can't just put the Bean in the request object without having the performView method recreate the Bean and put the new Bean in the request object. We can use the Bean again in the conversation. But if you do that, the data will be out of date. If we make a change in edit mode, we need to notify the change and refresh the data Bean in the State method. To simplify this process, we will only get the data Bean in the State method for MainViewState.

So, in the MainViewState class, the actionPerformed method does not handle it separately, but simply sets the MainViewState.

Subclass 4:StateManagerPortlet class

When the actionPerformed finishes processing, control is returned to the portal container so that other listeners notify the handler to execute. The portal container then continues Portlet request processing by calling the service method of StateManagerPortlet.

StateManagerPortlet's service method first attempts to retrieve the state class set by the previously performed action class, and if no state class reference is found (for example, the initial Portlet call), a helper class InitialStateManager is used to determine the initial state class for each Portlet pattern. InitialStateManager has a unique method called getInitialState, which returns an instance of the state object based on the current mode of Portlet. For downloading the product list Portlet, this class returns an instance of MainViewState for the view mode.

The State interface has a unique method, performView, which all state classes must implement. This method is called by the service method of StateManagerPortlet.

Subclass 5:MainViewState class

MainViewState's performView method is responsible for getting the list of downloaded products in the list form of Contacts Bean, saving the list of downloaded products in the database, and passing it to JSP for rendering in the main view.

Subclass 6:MainViewState class

This subclass allows the user to click on a downloaded product entry and then display a detailed view of the downloaded product.

The href used for this tag uses createURI tags from the Portlet tag library. This tag takes parameters in URIAction, and URIAction is set to the name of the event handling method used for the user's click action in the action class.

Subclass 7:actionPerformed

The actionPerformed class is used to view the main listing displayed on the JSP. Users can select a specific download product entry from the main view page to get more information. We also added an anchor tag to display the name of the downloaded product item as a clickable link, and when clicked, the actionPerformed method of StateManagerPortlet is called by the DetailViewAction class.

The actionPerformed method gets the selected download product entry object id, and invokes the proxy of the persistence class to get the instantiated download product object for the id. This download product object is placed in a session of the State class to render the details view. If the page is refreshed due to a refresh of the portal page, the Bean will be available in the session, and since the object will only be updated by the user using Portlet, we don't have to worry about the data being obsolete.

Another key to portal page refresh is that the form data has not been reinitialized. If we try to get the object id of the selected download product as the request parameter of the status class, it will not be available when the portal page is refreshed. Therefore, in order for Portlet to work properly, you must retrieve the data element at the beginning and store it somewhere so that it can be referenced when the page is refreshed later. Since the actionPerformed method has been called, this is a good place to store this code.

Keeping back-end data access in the actionPerformed method ensures that we don't need to access the database multiple times for the same data when the page is refreshed. Of course, the time and frequency of returning to the data source for data refresh depends on the requirements of the Portlet, as well as the factors of the data itself. In this case, the data is not dynamic and should be cached when the Portlet page is refreshed.

Finally, DetailViewState is set to the next state of the Portlet, and for Portlet, processing continues.

Subclass 8:DetailViewState class

DetailViewState simply calls JSP to render the details view, and JSP gets the downloaded product Bean from the session. In the UI interface, when the user clicks the "OK" button, the processing returns to the main view to continue. The actionPerformed method of MainViewAction simply deletes the session data by deleting the download product object id that we set in the DetailViewAction class.

Subclass 9:ViewProductAction class

The ViewProductAction class is used to display the JSP page of the downloaded product details view. Flow logic is done in a well-organized way, and you don't need to use cumbersome control code in Portlet. The editing and configuration mode of Portlet is implemented in the same way.

2. Complete the Portlet implementation

The rest of the application still follows the development pattern described above. The editing mode handles the control logic flow exactly the same as the view mode. We implement a configuration mode that allows users to specify data sources to hold downloaded product data. It will be implemented in the same way. Configuration mode has only one view to allow users to access the data source, and two other classes to verify the data source and save the data source as configuration data.

The following are the basic steps for implementing the state pattern.

The initial state class for the particular pattern being executed is provided by the InitialStateManager class.

The performView method of the state class, whose call is dispatched by StateManagerPortlet, does any necessary application logic processing, and then calls its JSP.

Associate each user's action with the name of the action subclass in which the event is handled through a parameter on PortletURI. Each user action generally specifies a different operation subclass that implements a single, specific function.

When the user clicks a link, the actionPerformed method of the action class is called (again because it is dispatched through StateManagerPortlet). Execute the operation logic and set the appropriate state class to allow processing to continue.

When the event handling is complete, the StateManagerPortlet's service method is called and again dispatched to the state class set during the Action event handling phase, which executes the application logic and calls its JSP to render the result.

When the user browses the entire Portlet, the operation continues in this way.

3. Persistent agent

Additional Portlet components are required to access persistent data in the database. The AbstractBroker class provides general JDBC database access capabilities. It can be used to get the DataSource and Connection; of the database it caches DataSource in the cache to avoid repetitive, costly JNDI lookups; it also provides generic code to execute PreparedStatement and turn off Connection, Statement, and ResultSet.

The ContactListBroker class inherits AbstractBroker, which implements data access methods specific to Portlet needs, such as the getContact method and the getContactList method, to save or delete entries from a list. It also has the ability to verify the table Schema so that we can verify the data source specified by the user in configuration mode.

4. Exception handling

We have implemented a large number of exception classes for Portlet, and the basic class is that AIMException,AIMWrapperException is a subclass of AIMException. You can use AIMWrapperException to encapsulate other thrown exceptions to efficiently modify display behavior and manage exception handling in StateManagerPortlet's service method.

AIMMessageException is a special exception that allows a reporting or error message to be generated to Portlet when processing is terminated. For example, you can throw an AIMMessage exception with a message indicating that the user must log in first.

Exceptions thrown in the actionPerformed method or setState method are caught and delayed to the service method. The way to manage latency is to catch all exceptions thrown in these methods and put them (usually wrapped in an AIMWrapperException) on the request object. When calling the service method of StateManagerPortlet, it first looks for deferred exceptions, and if so, re-throws and handles them from here.

Therefore, all Portlet application exceptions are handled in the service method of StateManagerPortlet. If an exception is found, the exception method is called in two cases: the exception message will be displayed in Portlet, and the exception message and associated stack trace information will be displayed. Keeping stack trace information outside of Portlet helps you debug at development time. This behavior is configurable because you do not want to display this level of detail to the actual application user. This is the debugTrace parameter defined in the deployment descriptor.

5. Establish a development environment

If you use WebSphere Studio to create this Portlet, make sure that the build path of the following JAR file is available so that the Portlet code can be compiled smoothly. If you use Portal Toolkit in Studio and create a Portlet application project, the classpath will be created automatically. In either case, you can create a Web project or a Portlet application project, and then import the downloaded WAR file to load the Portlet application into Studio.

SERVERJDK_50_PLUGINDIR/jre/lib/rt.jar

WAS_50_PLUGINDIR/lib/dynacache.jar

WAS_50_PLUGINDIR/lib/j2ee.jar

WAS_50_PLUGINDIR/lib/servletevent.jar

WAS_50_PLUGINDIR/lib/ivjejb35.jar

WAS_50_PLUGINDIR/lib/runtime.jar

WAS_50_PLUGINDIR/lib/ras.jar

WAS_50_PLUGINDIR/lib/naming.jar

WAS_50_PLUGINDIR/lib/utils.jar

WPS_V5_PLUGINDIR/portlet-api.jar

WPS_V5_PLUGINDIR/wpsportlets.jar

WPS_V5_PLUGINDIR/wps.jar

If you are not using Portal Toolkit or Studio, you can find these files in / lib and / shared/app.

When Portlet is deployed in a WebSphere Portal environment, all necessary JAR files are packaged at the same time. You can install the Portlet WAR file in Portal without making any changes.

1.3.5 implement Portlet with RAD

For starters, we graphically introduce the use of the development tool RAD (Rational Application Developer) provided by IBM to create, develop, debug and package Portlet.

In principle, I took screenshots from the beginning to the end of the installation, but in order to make the hierarchy clearer, we will introduce them in the following seven steps.

1. Install RAD and create portlet

On the Windows 2003 Server system, in the Control Panel → Advanced option, click the Settings button, select the data execution Save panel in the dialog box that appears, and click add. Button to add the installed rationalsdp.exe and enroll.exe to the list.

Open RAD, click the "New" button, select "Project" → "Portlet Project", and then enter the parameters in turn, including the name of Portlet, package name, whether to use the vault, and so on.

Parameter value

Portlet name DownLoadConfig

Portlet type basic Portlet

Web features use Web diagrams and JSP tag libraries

Whether you need to add an action listening instance is not required.

Whether it is necessary to add vouchers is not required.

Use mode display mode, edit mode, cultivate mode, help mode

Click the "finish" button, and Rational starts creating the Portlet automatically, and automatically opens the "DownLoadConfigView.jsp" file after creation, as shown in figure 1-10.

Figure 1-10 developing Portle in RAD

2. Create and design the required action classes (Actions)

Create an Action package: com.ibm.csdl.portal.download.config.actions, and create the following classes in this package, as shown in figure 1-11.

Figure 1-11: the operation class created

These classes implement all the operations of Portlet, and let's take "delete a CD or E-mail for product configuration" as an example to see what functions Action implements.

In the actionPerformed method, the program receives the parameters passed from editAProduct.jsp, that is, the values passed from the CDs and Emails selection boxes, to see whether to delete a CD or an E-mail, and then delete the corresponding CD or E-mail from the product configuration object, and finally write it back to the XML file.

In the setState () method, the program instantiates a RemoveOneCDsOrEmailState and hands the logic to State. So, how does State flow? Look at the State class below.

3. Create and develop the required state classes (States)

Create a State package: com.ibm.csdl.portal.download.config.actions, and create the following classes in this package, as shown in figure 1-12.

Figure 1-12 status classes created

These classes implement all the state mode transitions of Portlet, and let's take "remove a CD or E-mail for product configuration" as an example to see what functions State implements.

The RemoveOneCDsOrEmailState.java code listing is as follows:

There are only two methods in the State class, one of which is used to get an instance, and we don't care; the other is performView, which is responsible for reading out the contents of the XML file (which is now modified), and then putting it into Session, calling and initializing a new specified JSP file. The JSP takes the data from the Session and initializes it.

4. Create and develop the required data structures (Data) and Portlet classes

The Data class mainly defines some data structures, which are used to store the data in the XML file, which has nothing to do with the development of Portlet.

The Portlet class is mainly used to initialize some data and call the corresponding JSP page according to the state of the Portlet.

The resource file under nls is related to the multi-language support of the browser. According to the settings of the client browser, you can take out the static description file Portlet.xml from the corresponding resources, and then complete the initialization process in the JSP file.

The com.ibm.csdl.portal.download.config.utilities package mainly handles some exceptions (see figure 1-13), which I won't repeat here.

Figure 1-13 com.ibm.csdl.portal.download.config.utilities with common exception handling logic by default

5. Create and develop the required pages (Pages)

Based on the detailed design above, we need to create some pages, as shown in figure 1-14.

Figure 1-14 created page

The functions of these pages are as follows.

The display logic of the page is brief. Let's take ViewAllTheProduct.jsp as an example to see how Rational adds action event listening to a link.

The ViewAllTheProduct.jsp source code is as follows:

In fact, it is very simple. You can add the action event listening for the link with a hyperlink, as follows:

Others are similar, and I will not repeat them here.

6. Debug Portlet

Assuming that there is a Portal system running on 9.181.66.250 and the user name and password of the Super Admin are admin, we can create a server to test Portlet, as shown in figure 1-15.

Figure 1-15 create a Portal server in RAD to debug Portlet

Select the type of server as WebSphere Portal, and enter the relevant parameters.

Right-click the project name and select "run" → "run on the server", as shown in figure 1-16.

Figure 1-16 choose to run Portlet directly in RAD

After a few minutes, a browsing page appears in the workspace so that you can debug the Portlet.

7. Package and generate products

Packaging Portlet is also very simple, right-click the project name, select "Export" → "WAR file", and then select a good storage location, as shown in figure 1-17.

Figure 1-17 Export Portlet as a WAR package and deploy to a Portal server

With this WAR package, you can publish or update it to the Portal system.

1.4 Portlet development guidelines and sample implementation

Familiarity with Portlet development guidelines and sample implementations gives you a good understanding of Portlet API. However, the implementation of complex process control is beyond the scope of API. If you don't have a well-defined method to solve the problem of how best to implement the control logic, you can't create Portlet-- that contains simple and reasonable code that specifically locates the purpose of the user's request.

In addition to repetition, this code makes Portlet more difficult to read because you need to enter the control logic to get the actual work that Portlet is doing. Control logic is also error-prone because it depends on a variety of situations, such as using string matching to concatenate events and listeners, or Action in listener actions and Portlet methods. To solve these control logic problems, you can think of the application as a collection of Portlet operations and states, and then perform state transitions through a well-defined method, so that you can remove the cumbersome control logic code from the Portlet application.

Developers can also choose to use the Struts framework to implement Portlet. Struts is a Jakarta project that provides a very popular open source framework for building Web applications. Using Struts Portlet Framework with Portal, Portlet written in the Struts framework can run on WebSphere Portal. Struts provides Web applications worth considering, which go far beyond page navigation and are a good choice for Portlet development. Developers who are not familiar with Struts or want more direct access to Portlet API will benefit from the implementation of state transitions for page navigation. This pattern, like the Struts framework, improves the application framework for MVC design.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.