Team. We have already stated that we would not be much competition for the Oracle. Basically, we would be "scrubs" on the tournament roster. Knowing that we would be "erased" from the competition brackets as a "non-contender" before any play began, the CABOOSE team is simply seeking a place near the Oracle bench when the action commences.
In this vein, we will be reviewing some of the goals, features, and characteristics of the Ozark product as we continue with our CABOOSE effort. The following is a summary of the first chapter in the MVC: Model-View-Controller API dated March 25, 2015. It is listed as the Early Draft of Version 1.0. A complete PDF of the document can be found at hyperlinks found previously in this weblog. With this summary will be some technical commentary.
The model-view-controller (MVC) architecture is the most common one among HTML web applications. It comes in three fundamental parts.
Firstly, the model comprises the entity classes associated with the application's data. Within the CABOOSE controller pattern for servlet, we encapsulated HTML templates associated with the view in the model. These templates represented view specifications which the controller would provide for a client application which could render the desired view instance based upon their specification and other appropriate data from the model. In short, these templates were models of various views within the application.
Secondly, the view is a rendering of data within the model whether in a CABOOSE pattern or traditional MVC application. The view represents a boundary and interface between the system user and the application. Input validation concerns in an MVC should be handled by the client when every possible. This limits traffic between the secondary and primary processes. This frees the primary process for servicing more clients and increases web query throughput.
Finally, the controller marshals the flow of data between the entity classes and the view. One can design a controller in a number of ways, but a simple interpretation of the abstract controller is as a command or message processor. The controller receives a request message (command) and provides a response message (command). As such, the abstract logic governing a controller is: read a request on the input stream, process it, and finally, write a response on the output stream. The challenge in writing a controller well is the logical details of the "process it" step.
The MVC architecture comes in more than one form. Among desktop applications the most common form is the Type-I architecture which allows a callback between the view and model so the interface content refreshes itself with "real-time" accuracy.
Achieving this is more challenging on the web. So, a view refreshes itself with each HTTP request of the webserver. As a result, view data can conceivably be "stale" based upon the actual state of the entity classes. This form of MVC is called a Type-II.
The Type-II MVC fits the natural layered architecture that arises from working with networked enterprise applications. The early editions of these from around the millennium contained four layers: the presentation layer which contained the view, the business logic layer which contains the controller, a layer for middleware technologies, and finally the entity class layer which contains the data. Forgive us, if we have misspoken about the content in each layer of these early models. This was stated from memories which are nearly a decade old and have not been refreshed by reading older text. The latest web-based layered models have only three layers. The business logic and the middleware layers have been merged.
Some might say "Wrong!". A Type-I MVC is the mixture of servlets and JSP in an application working in similar roles for returning content, and the Type-II MVC is an advance in thinking were the servlet fulfills the role of a controller which returns a JSP/JSF as a view. You know we would not argue with you, because you would be absolutely correct. Yet, we would add that we are also!
We have called this distinction made among MVCs Style-I and Style-II. This removes the ambiguity of using the term "Type" in both places. Computing is a rather new field which lacks an abundance of terms for uniquely describing every concept and a rich set of synonyms for variety in description. But, this is a topic which could fill many books and not the purpose of these few paragraphs.
The Oracle documentation describes web user interface frameworks as action-based or component-based. It states that in an action-oriented framework the controller which fields each client HTTP request maps them with server-side actions in application code. In contrast, component-based frameworks use server side components for the processing of request with very little interaction from application code. So, in a component-based application, the framework encapsulates the majority of controller logic. This it has abstracted away from the application.
The MVC API provided by Oracle is an alternative for component-based systems such as JSF and not an intentional replacement.
A Summary of the Goals of Ozark MVC API are:
a. Make the most of the existing JAVA EE technologies.
b. Provide seamless inter-workings with CDI and Bean Validation
c. Define a solid kernel of features for MVC development. All of the features might not be implemented in its first version.
d. Consider building upon a JAX-RS foundation so Ozark might reuse its matching and binding layers.
e. Provide inherent support for JSP and Facelet view languages.
The following are not goals of Ozark:
a. The creation or definition of a new view (template) language or processor.
b. Support stand-alone implementations of MVC running outside of the JEE.
c. Support Restful services which are not based on JAX-RS.
d. Provide built-in support for languages which are not part of JEE.
This summarizes the first couple of sections of chapter one which are the bulk of the reading for it. We will provide a synopsis of the third through seventh section on 05.29.2015.
Please pardon any typos. This text was created in “fun-mode” as the German descendants in my locale say. Things have been busy and tons of “fun” for the past couple of weeks.
Happy Coding!
The CABOOSE Team
No comments:
Post a Comment