Conclusion

It is the recommended way to build enterprise applications using Java by Sun Microsystems. That JSP is a recommendation might be a good enough reason to choose to use it, because of the great support it has in the market.

To write a well designed application, JSP strict code design policy had to be introduced, one has to implement some kind of abstraction layer, and create some distinctions between the layout and business objects. The recommended way to do this is to use the Model 2 MVC model specification from Sun Microsystems.

3.4 JSP/Struts (Model2)

3.4.1 Introduction

Struts [struts] is a Model-View-Controller [Gamma 1995] pattern project handled by the Jakarta Apache group. It consists of a framework of classes that implements a Model 2 MVC model, described in the Java Blueprints document [j2eebp], and in appendix B in this master thesis. The main ability of Struts is its comprehensive integration with the J2EE model, leveraging techniques as Java Server Pages, Java Servlets, Java Beans, Enterprise Java Beans etc.

Model 2 essentially means implementing MVC with a Servlet functioning as a controller that takes care of incoming requests, sends them to the model, and then forwarding the results to the View, represented as JSP pages. An illustration of this can be found in appendix B.

3.4.2 Overview of Struts

The MVC model in struts is built upon a framework of other design patterns. The term "design pattern" is commonly used in the IT industry, and is described thoroughly in the book "Design Patterns" [Gamma 1995].

The controller is implemented using the "command" design pattern that updates the business model through action objects that works according to the "adapter" design pattern. The action objects are the only way to communicate with the business objects from the designer's point of view, which ensures that there are strict rules for how to communicate with the application from the graphical user interface (GUI).

The view, or the GUI, consists of JSP pages with custom made tags, which are preferably used instead of adding Java code inside the JSP page.

3.4.3 Analysis results

Design and Maintainability

MVC models are usually constructed for making the maintainability of a system easier. And the same applies to Struts: It is easy to change the Views without touching the business model. The requests to the business model are nicely structured in different action objects. A problem though is that JSP invites the developer or the designer to potentially enter business logic into the view and thereby destroying the structure build up by Struts. This is especially true with projects that has a short developing time. But with discipline and well balanced projects, this hazard could be minimized, nevertheless it is a drawback. See also the study of JSP in chapter 3.3.3.

Dynamic layout

Except for separating the data from the design, there is no additional help to create the dynamic layout we are looking for in our prototype, because the JSP pages are templates that are static in nature. One solution to a dynamic layout would be to create JSP pages inside Caleigo's source code generator, but then the layout would still be static, although easier to re-generate.

Areas of responsibility

If the designer strictly follows the Struts model, he is limited to using the action objects created by the developer. The action objects can be created in an earlier stage, before the designer is introduced to the project. Using the action objects ensures that there is a rather clear distinction between the work done by the GUI designer and the developer.

Demands on skills

From the designer's point of view

Since the view consists of JSP pages, there will be a need for the designer to have basic Java knowledge which must be seen as a drawback. Struts does alleviate some of the more advanced Java implementation with well constructed custom tags that encapsulates the model, but the syntax is not straightforward for a HTML designer.

From the developer's point of view

It seems that there are a certain threshold to overcome, but the time required to overcome it is acceptable. Since the MVC model is based upon the Model 2 MVC model from Sun, there are a lot of source materials to look into for help.

Feasibility for small and large projects

The structure enables support for larger projects. For large and complicated projects with dynamically changing views, there can be a risk that the model is too rigid.

Connections to business logic and/or databases

Struts uses action objects that wraps business logic. There exist one action object for every interaction that a client can make with the logic. Struts also helps with the interaction with a database by providing a primitive data access framework.

Learning curve/threshold

It takes some time to understand the inner working of Struts, but the threshold is not that high. The GUI designer might need to write Java code in the JSP pages if the developer has not provided him with custom made tags to access the business logic. Otherwise, the developer has to provide the designer with a business logic interface.

State handling

Struts uses the Java Session object to handle the application states for the user.

3.4.4 Conclusion

It is a popular framework on the market.

The extra functionality included in JSP is not helping us out when we want to create the flexible layout we are trying to achieve.

We believe that the design of Struts is not very elegant. It seems to have had a good start, but have become a bit bloated when problem areas have been discovered along the way. Of course our limited time to investigate these suspicions might not give Struts justice on this.

3.5 Tapestry

3.5.1 Introduction

Tapestry is an object driven model for creating dynamic web pages. It can be compared to traditional GUI libraries such as Swing, with the intent to mimic the component models. It is based upon that the designer should not need to know a scripting language when designing a web page. The method used to inform tapestry where to insert data is to add an identification to the standard HTML tags. The tags will then be replaced with content retrieved from components by the Tapestry engine when the

application is executed. The components are written by the developer to provide the page designer with data from the business logic. This makes it easy to separate the designer and developers tasks.

An example of a Tapestry application can be found in appendix D.

3.5.2 Analysis results

Design and maintainability

Tapestry systems are highly maintainable, since the separation of logic and layout is very good. Templates can be changed at any time by a designer, without having to change the components that provides the page with data, unless of course the designer wants to make fundamental changes to the logic of a page. It is a similar situation with the developer, who can change the underlying business logic, as long as he does not change the interface in the components against the templates.

The re-usability of components are one of the really strong points of Tapestry, but it requires a good component based design of pages and their subparts.

Dynamic layout

Tapestry has the potential to be able to create really dynamic layouts, with its ability to create hierarchies of components, nested inside each other. One thing that still is a bit unclear to us is if the components are dynamically exchangeable at runtime. If this is the case, the Tapestry technology would be a very promising technology for creating highly dynamic views.

Areas of responsibilities

The developer creates the components and gives them their abilities, he would most probably create a rudimentary template including all component functionality.

The designer can freely design the template as long as he saves the Tapestry id attributes within the HTML tags.

Demands on skills

From the designers point of view

The page designer only need be skilled in HTML. The most likely process used to create Tapestry applications would be for the designer to get a rudimentary HTML design from the developer, with the Tapestry IDs included in the HTML tags. The designer has to be careful not to alter any tags to prevent the view logic to be changed. He would need to understand some programming logic when creating conditional loops and iterations with Tapestry, but they could be inserted beforehand by the developer. From the developers point of view

The developer needs to be skilled in Java, together with a good understanding of the Tapestry framework. The tapestry framework seems to be clean and structured, no strange workarounds or illogical statements were found at first glance.

Feasibility for small and large projects

Tapestry should be perfect for large projects, with its clear separation of layout and business logic with its component based model.

Tapestry might be an overkill for smaller projects, due to the time it takes to set up a system, but it may still be worthwhile if the project is likely to grow.

Connections to business logic and/or databases

Connections to business logic are done through Java Beans associated with components. They are responsible for the state of the component and any eventual data it holds, and are much like a GUI component in Swing, which is the component model used in Caleigo's smart clients.

Learning curve

Tapestry can be a bit tough to master, when being confronted with it the first time, but when the concepts and the design is understood, the threshold could be passed. There are a lot of configuration steps to be done before seeing the results, but from the designer's point of view, there is no problems, since he sees the resulting page, filled with dummy data, from the start.

State handling

State is preserved in two ways: Either in the Java Beans, used as value holders, or in a so called Visit object that can be created per session and can contain global data for the session. These Visit objects are created when needed and they trigger the creation of a Java Servlet Session object, used to store the data in the background.

3.5.3 Conclusion

Tapestry looks like a very promising framework to create a dynamic layout, because the components can be nested inside themselves.

The templates are free from scripting language codes, and they are filled with dummy data where the dynamic content should be inserted. This enables the designers to emulate the finished result inside their page creation tools.

Tapestry is an open source project, for good and bad

3.6 XMLC/Barracuda

3.6.1 Introduction

XMLC

"Enhydra XMLC is an XML compiler that converts document templates, including HTML, cHTML, WML, XHTML, and custom XML, into resources that can be directly accessed from a Java program using standard DOM manipulation syntax." [xmlcp]

The document formats listed above all contains markup languages. A markup language adds extra information to text by encapsulating the text in question with elements from the language. HTML is used for adding layout information to a text, XML is a generalized language that can be extended with user defined elements.

XMLC makes use of the fact that all markup languages above has a way to identify part of text, by adding an identification parameter to the markup language element. An example of an HTML document, with the ID parameter, is listed below:

<H1 id="header">Welcome to this page</H1>

<DIV id="text">It is under construction at the moment</DIV>

In the example, we see plain text with the elements H1 and DIV surrounding parts of the text. The elements are used to tell a web browser how to render the texts within. The identification parameter is ignored by the web browser.

When XMLC parses the example above, it identifies all parameters that includes the identification parameter. After compilation of the page, a resulting Java class is created which is an object oriented representation of the text document. The class contains methods for manipulating the text it represents, together with special help methods for accessing the text parts containing the identification parameters. The class conforms to the Document Object Model (DOM) interface [DOM1], which is a standardized way of how to represent documents with objects.

The XMLC technology aims at separating the UI design from the business back-end to an extent that designers will not have anything to do with the data flow and content. The designer would only have to add the identification parameter in the document where dynamic content from the application should be inserted. The developer works with a Java object which represents the complete document. He or she uses the methods in the object to add, modify or remove content, which makes the developer more or less unaware of the look of the document layout.

XMLC gives:

A well-formed XML / HTML documents No custom tags are included in the document A well defined line between design and logic XMLC does not give:

An abstract way for providing the document with dynamic information

The Barracuda project

XMLC does not supply the developer with any other functionality than compiling a text document into a Java object representation. To be able to create an application, there is a lot of other things required, such as an MVC model to add interactions to the layout, for altering the application state. Some framework for handling the dynamic content in the Java object compiled by XMLC has to be created, otherwise the developer needs to change the code every time the designer changed the structure of the page.

The Barracuda project consists of different kinds of frameworks that could be used as front-ends to the XMLC technology. For example, there is both an MVC model and a template engine which both could be used to help the developer to create applications based on XMLC. The Barracuda project also contains a collection of objects that helps with rendering HTML. They exist to help the developer with adding dynamic content from the application that should be rendered as HTML on the client.

3.6.2 Analysis results

Design and maintainability

The GUI designer has to write well structured HTML documents. He or she adds the identification parameter to all markup elements where dynamic data should be inserted. The developer gets compiled Java objects from XMLC and uses other tools, for example Barracuda, for creating an application framework that interacts with the Java objects generated by XMLC.

The maintainability for the designer is very straight forward, there are no special tags in the HTML code, all tags are conforming to the HTML standard. He has to rely on developers to populate the document with data, but he can add dummy data to emulate the finished look of the application. Due to lack of information about how to get Barracuda up and running, we could not evaluate the ease of maintainability for the developer. Presumably, the developer has to be skilled in object oriented software creation even though Barracuda promises to help.

Dynamic layout

XMLC gives great flexibility in the layout because the complete document is accessible on server-side, as a Java object representation. The document can be altered by adding, changing and removing nodes and entities at those nodes marked with an identifier in the document. The way to alter the nodes are standardized according to the Document Object Model interface [DOM1].

Areas of responsibilities

The designer is responsible for the layout of the document, which will be used as a template for the developer. The designer can add temporary data to the document to emulate how a complete layout would look like. This means that the designer does not need to know any Java to produce layout that provides dynamic layouts.

The developer does need to be engaged with generating layout data, since he is responsible for adding dynamic content to the layout page. The Barracuda project contains a collection of Java objects that represents HTML elements. The developer can feed these objects with dynamic data and then let them render the corresponding HTML code by calling the rendering method. Although they make it easier for the developer, he still need to be concerned with layout issues.

Demands on skills

The designer has to understand the importance of writing documents that conforms to the DOM standard. Knowing how to write well-formed documents is often a required skill for web designers due to the need to do so for other technologies to work. The document designer does not have to know anything about the underlying business logic and data flow.

The developer needs to have a high level of competence in the DOM standard and how to write well designed web applications, even though the existence of the Barracuda project. This is because both XMLC and Barracuda are highly ambitious projects, using very high levels of abstractions in the interfaces. It is not intuitive how to connect the projects together, and things can be done in many

ways. Another factor that makes it even harder to develop anything using these technologies is that the documentation found on the Barracuda homepage is limited at best.

Feasibility for small and large projects

These technologies are probably best suited for really big projects that requires a clean design and strict rules for how to create content. It is not suited for smaller applications, since it is very hard to get started, and it requires a lot of object oriented analysis to create a framework for how to deliver data from the business logic to the clients.

Connections to business logic

Since the document is compiled into a Java class, the developers have complete access to what flexibility Java provides. Real-time configuration of the views, like in the Swing clients, should be possible to do in a a highly dynamic fashion.

Learning curve / threshold

The learning curve for the developer is very high, due to the reasons described above.

State handling.

The state is handled by the frameworks in the Barracuda project, but even the document itself keep a level of state, since it is a Java object on the server.

3.6.3 Conclusion

Both technologies in conjunction looks promising for larger projects. If the level of the documentation improves for the Barracuda project, it could be interesting to look further into these technologies.

3.7 Velocity

3.7.1 Introduction

Velocity is a template based scripting language, created by the Jakarta-Apache group [jakvel], well suited for adding dynamic data to static templates. It has built in functionality for creating dynamic web pages.

Velocity can effectively replace JSP, Servlets and other HTML producing technologies. One of the