In the JSP MODEL 2 model, all users' requests are submitted to the Controller Servlet, unified allocation by Controller, and the different UI is displayed to the user. This push mode is an advantage in many people because the specific push UI in the MVC implementation of Struts can be configured in the configuration file. After the configuration is completed, the entire site map can be obtained through some visual analysis tools. The basic access format in Model2 mode is:
Action.do? Other parameters
I have never used Model2 mode, but compared with our JSplet framework, I think this kind of push is not the advantage in most cases. If a web access is considered as a function call, follow the model2 mode, the return condition of this function is uncertain, and you need to be determined by an additional profile. And we know that a function of an incomplete number is generally not a good design. In our frame design, a basic point is to try to expose freedom to people actually control it. In fact, in most cases, the page preparation knows which page should use to display data, they do not need an additional profile. JSplet uses the following URL format: View JSP? ObjectName = Model Object Name & ObjectEvent = Response Event Name & Other Parameters to give a specific example: http://my.com/demo_view.jsp?objectname =/@demo&OBjectEvent=test
Demo_View.jsp is the specified display page, which is as follows: [code] <% @ include file = "/Engine.jsp"%>
WebEngine also maps ObjectEvent to an Action response function and automatically calls it, and the specific Action code is written in a separate Java file or JSP file. DemoAction.jsp [CODE] <% @ include file = "/jsp_action_begin.jsp"%> <%! // // Objectname map to thisobj, ObjectEvent = TEST mapping to acttest's call // After adding an ACTXXX function, That is to access by ObjectEvent = XXX, no need to configure the variables in public object acttest () {// thisobj to use thisobj.set ("Testvar", "Hello") in the view; Return Success ();
// If there is an actbeforeaction function, the function calls public object actbeforeaction () {return success before all ACTION functions.
/ / If there is an actaFteraction function, then the function calls public object activity ();}%> <% @ include file = "/ jsp_action_end.jsp"%> [/ code]%> [/ code]%> [/ code]
Only registration objects are required in the jsplet framework without registering each Action separately. Register.jsp [code] <% WebEngine.registerType ("Demo", New WebActionType ("/ Demo / Action / DemoAction.jsp"), PageContext);%> [/ code]
Compared with the JSplet framework, Model2 is modeling the action instead of the modeling of Object, ie it is equivalent to binding ObjectName, ObjectEvent, and View.jsp to be defined as an access point action.do, the binding process A configuration file is cured between view.jsp and action. Therefore, Model2 does not completely separate view and model, which implies ObjectName only has an ObjectEvent, and is bound to a specific View (except for error pages). For example, we need two different views to display the same data, you may need to configure two separate access points in the Model2 program, and only use two different URLs in our framework: a_view.jsp? ObjectName = / @ Demo&OBJECTEvent=testb_view.jsp?objectname =/@demo&bjectEvent=test The same web program can even be called in the front desk with an additional configuration!
In the JSplet framework, it is an object-oriented manner, there is a variety of object-oriented extensions, and all extensions are directly refinered in the URL format, everything is in the sun. Objectname in jsplet is the name of WebObject, unique in the full system, the format is defined as: ObjectScope @ ObjectType $ ObjectInstanceID1. Object Type ObjectType We need to register the object type instead of a complete object name, an object type can correspond to countless A complete object name, for example we registered with the demo type WebObject, ObjectName = / @ Demo and ObjectName = / Left / @ DEMO corresponding to DemoAction.jsp. 2. Object lifecycle Control ObjectScope ObjectScope is the domain where WebObject is located, and its format is in line with UNIX path naming specifications. The JSP model itself supports some predefined object domains, including Page, Request, Session, Application, and so on. However, in order to reflect the object tissue structure in the real world, the object domain must be customized. Objectscope is organized into a tree structure, which is a basic control structure that controls the object where the object must exist between the simultaneous object domain. When the system accesses an object, if the object is located The domain cannot be at the same "path" at the domain of the existing object (ie, when the parent child relationship between the object domain) is automatically destroyed, all objects under the non-compatible path branch are automatically destroyed. This fine control policy guarantees the scalability of the system because the model ensures that only part of the object is created. Object Transfer System Action / Main / @ MyObject ==> / Main / Left / @ OtherObject None / Main / Left / @ OtherObject ==> / Main / @ mObject None / Main / LEFT / @ OtherObject ==> / Main / LEFT / @ MyObject No / Main / Left / @ OtherObject ==> / Main / Right / @ MyObject Auto Destroy / Main / LEFT Subdomain Object 3. Object Instance Identifier ObjectInstanceId A object is required to contain multiple objects in a domain, which can be distinguished by ObjectInstanceID, so we can use multiple objects on the same page.
Another extension in the jsplet is an objectification of the JSP sub-page through the event route. For example http://my.com/demo_main.jsp?objectname=/@main ,ttarget=/@sub&ObjectEvent=test If the EventTarget parameter is specified, the ObjectEvent is responding to the object corresponding to the EventTarget. Inside the JSP file we can introduce sub-objects through the include syntax, such as
[/ code] In this configuration file, demoaction.jsp and demoAction2.jsp are chain relationships, ie in the propagation model of the event response, if Event is not marked as stoppropagation, will be passed to the next listener.
In summary, it can be seen that MODEL 2 is not a very perfect web program mode in the currently variable demand environment, and some important design needs are hard to get appropriate expression in the pushes of Model 2 mode.
