CONTENT MODELS AND VIEWS—A SPECIFIC DESIGN PROTOTYPE

The model contains the core of the application’s functionality. The model encapsulates the state of the application. Sometimes the only functionality it contains is state. It knows nothing about the view or controller. The view provides the presentation of the model. It is the look of the application. We apply predefined user know functions on the view to present the application’s look. The view is notified when changes to the model occur. The business logic updates the state of the model and helps control the flow of the application. Action classes as a thin wrapper to the actual business logic accomplish the tasks. The model represents the state of the application. The business objects update the application state. ActionForm bean represents the model state at a session or request level, and not at a persistent level. The JSP file reads information from the ActionForm bean using JSP tags.

Our goal was to develop a minimal prototype that can demonstrate the functionality we are striving towards. Since the XML parser is brought up on the system. Let us start to write tag descriptors for certain generic tags. You can use what tag library or functions there are basic prototype assumption: the layer transparency rule. To each view, there corresponds generic functions that are deployed from the business logic layer to key onto the data layer. Example Tags want to allow the JSP to name the generic functions that the business logic layer deploys, stating certain characteristics and conditions on the functions. Simple example Tag the JSP states I want F1 and F2 and that F1 and F2 are returning values meeting my criteria. We applied Struts MVC model further on. The model contains the core of the application’s functionality. The model encapsulates the state of the application. Sometimes the only functionality it contains is state. It knows nothing about the view or controller.

Model: The model contains the core of the application’s functionality. The model encapsulates the state of the application. Sometimes the only functionality it contains is state. It knows nothing about the view or controller.

View: The view provides the presentation of the model. It is the look of the application. The view can access the model getters, but it has no knowledge of the setters. In addition, it knows nothing about the controller. The view should be notified when changes to the model occur. Certain functions are provided on the view. Our Morph Programming techniques transmute the functionality to allow the controller to create a model. The model is created with functions that enable the functionality desired from the view, i.e., the presentations layer functions.

Controller: The controller reacts to the user input. It creates and sets the model.

The JSP are not entirely static, since there are tags allowed.

Study tags and customized tags: The design technique flirts with a new programming paradigm that can allow us to deploy tag descriptors to in part code business logic with functions that are transmuted through Struts view onto the content model. Let’s call it Morphic programming for the time being. Therefore, the ACID criterion is important, particularly, since Tags communicate with shared objects. MVC helps resolve some of the issues with the single module approach by dividing the problem into three categories:

Struts overview: Client browser

An HTTP request from the client browser creates an event. The Web container will respond with an HTTP response.

Controller: The Controller receives the request from the browser, and makes the decision where to send the request. With Struts, the Controller is a command design pattern implemented as a servlet. The strnts-config. xml file configures the Controller.

Business logic: The business logic updates the state of the model and helps control the flow of the application. With Struts this is done with an Action class as a thin wrapper to the actual business logic.

Model state: The model represents the state of the application. The business objects update the application state. ActionForm bean represents the Model state at a session or request level, and not at a persistent level. The JSP file reads information from the ActionForm bean using JSP tags.

View: The view is simply a JSP file. There is no flow logic, no business logic, and no model information—just tags. Tags are one of the things that make Struts unique compared to other frameworks like Velocity (Figure 10.5).

By placing the business logic in a separate package or EJB, we allow flexibility and reuse. Another way of thinking about Action class is as the Adapter design pattern. The purpose of the Action is to “Convert the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatibility interface” (from Design Patterns—Elements of Reusable OO Software by Gof). The client in this instance is the ActionServlet that knows nothing about our specific business class interface. Therefore, Struts provides a business interface it does understand, Action. By extending the Action, we make our business interface compatible with Struts business interface (An interesting observation is that Action is a class and not an interface. Action started as an interface and changed into a class over time. Nothing’s perfect.).

FIGURE 10.5 Struts overview.

Our design generates a content model for specific applications with Agent Object Model. The view provides the presentation of the model. It is the look, or the presentation of the model, and the look of the application. We apply predefined user known functions on the view to present the applications look. The view should be notified when changes to the model. The business logic updates the state of the model and helps control the flow of the application. With Struts this is done with an Action class as a thin wrapper to the actual business logic. The model represents the actual business state of the application. The business objects update the application state. The business objects update the ActionForm bean represents the Model state at a session or request level; bean represents the Model state at a session or request level, and not at a persistent level. The JSP file reads information from the ActionForm bean using JSP tags. Our design applies the same functions that are presented on the view for specific application to generate a content model for specific applications.

We can apply Content Model languages such as SGML to carry on the Model languages such as SGML to specifics at the parsing level. The view feels like a flyer with direct throttles onto the content engine. An example prototype was designed with a Humboldt University, Berlin student project some years before.