ELABORACIÓN DE PAPEL ETAPA 1

In this chapter, an analysis of the presentation framework of the prototype is presented. The questions that were raised in chapter 4, together with some other issues found during the analysis phase will be answered in this chapter.

The first, and probably the most interesting question to answer, is if we managed to develop a

framework for creating the dynamic views as discussed in chapter 4. The short answer would be "yes", and a slightly longer answer will follow after this introduction.

The second issue would be to use an existing template-based technology and see if it is possible to get the same functionality in the presentation layer, as when using our Gen-based prototype.

5.3.1 Dynamic views

In this chapter, a deeper analysis of the dynamic views is presented. The dynamic view concept is explained in chapter 2, and the implementation is presented in chapter 4. The thin client concept is discussed in chapter 1.

The presentation framework in the prototype is divided into two parts: Views and templates. This extra layer gives at least two benefits:

Views can be shared between templates

Different skills are needed for creating views and templates

The template engine is the part in the system that builds the necessary layout information needed for a thin client. It creates HTML pages for web browsers, and it can in theory create WAP-pages to be rendered in cellular phones. The layout is defined in template files, as described in chapter 4. The templates defines the static layout data inside the template document, and get the dynamic layout data from the views. The definition of the static and the dynamic layout data exists solely inside the

template, which makes the views more general than in the Swing counterpart. This means that different layouts can be constructed using the same view, as long as the dynamic data used in the templates are the same. The benefit of this is that making changes to a layout does in many cases not mean that the Java code has to be re-generated, the changes are done in the templates alone.

The conclusions above also leads to another interesting point, namely the second point. Since the templates are constructed using a scripting language, the skill needed for creating a template is different from the skill needed to create a view.

The developers that implement the views need to be skilled in the Java language and must be familiar with the object oriented way of thinking. The internal structure of CEL must be mastered in order to extract the layout information, however the developers do not have to be concerned about the layout, other than creating the API for the templates.

The developers concerned with creating templates have to know about the clients layout rendering capabilities and the language used to create the layout inside them. The developers also need to understand the scripting language used in the template files and what dynamic information the views can deliver.

Template issues

The layout is slow

The dynamic functionality of the views is, as stated in chapter 4, created by having a template

recursively include itself until an end point is found. The end point is called a base view and it contains the dynamic content that is specialiced for the view in question. When the template engine parses a template, a tree is created in memory to be cached during the life-time of the application. The first time a template is used in the application the parsing occurs, the next time the cached copy inside the cache tree is used. This makes the HTML rendering to be quite fast.

Our current prototype uses templates that in the end constructs a single HTML page. This means that there are a lot of views that recursively are getting called every time something on the HTML page changes. We do experience some performance issues when rendering the pages, but we have some good guesses of the cause of these issues:

There is a lot of debug information on the console, while rendering the HTML pages and writing text in the console is a time-consuming operation. This can be solved by simply removing the debug information.

The GeneralPropertySource and WebPropertyEnumeration classes, which are called inside the templates, are using the reflection6 _{functionality in Java, which is quite time-consuming, at least}

6 The reflection functionality makes it possible to call methods, or constructors, on objects of which you only know the name. The reflection framework uses the name and checks if the method exists

when it is being done a multitude of times inside the templates. The solution to this problem is to create special types of property sources and register them in a lookup service for a specific class. When a property source is needed inside a template, the special property source will be used if it correspond to the data that the template needs, otherwise the GeneralPropertySource is used, which can wrap any kind of data.

Web applications can gain performance by splitting up the layout in frames, which are sub-documents inside a frame set document. These frames can be updated independently of the other frames and thus a smaller part of the complete application has to be redrawn.

The Gen scripting language is proprietary

That the scripting language in Gen is proprietary might be an issue, since there are a lot less developers that knows about the Gen scripting language than for example the de facto standard JSP. This issue is not that big, because the scripting language is quite small and all template engines more or less share the same concept, which makes it rather easy to learn a new scripting language.

The templates might be hard to debug

There is no working environment today that supports debugging Gen templates. This can make debugging of thin client applications cumbersome, at least when creating templates that include other templates in an iterative manner, because it is hard to tell in which template an error occurs by just looking at the generated layout. Often errors might not even stem from the template itself, but from a Java object used within the template. If this prototype would be used as a base for a product, debugging facilities would of course be provided by Caleigo.

Conclusion

Templates are good because they separate data from presentation details, and it is an advantage when there are different roles collaborating to make the application. Templates have problems though, and we believe one of the major problem is the mapping of the object oriented view structure to a script based template structure. It is not a functional problem, but more of an architectural one. It can be quite a challenge to understand how an application is built up, by just looking at the templates, because of the vital recursive behavior in them.

5.3.2 Use JSP as a template engine

In this chapter, we will make a theoretical analysis of the similar functionality as presented in chapter 4 and id it can be created using JSP.

The concept used in the templates for creating the dynamic views are the "#INCLUDE" statement, together with the possibility to pass a PropertySource as parameter to the page. This concept is vital for the dynamic views to work and without being able to mimic this functionality in JSP, this project will fail.

In the JSP 1.2 documentation [JSP12], a <jsp:include> tag is presented as being able to dynamically insert other pages. The syntax for the tag is listed below [jspsx]:

<jsp:include page="{relativeURL <%= expression %>}"> <jsp:param name="parameterName"

value="{parameterValue <%= expression %>}" />+ </jsp:include>

There seems to be no way to pass an object directly to an included page, using the tag. One can supply additional parameters though, but they are limited to be only strings.

So, there exists a tag for including other pages in a JSP page, but there seems to be no way to give information to the included page. We need to check out the JSP concept a bit further to see if we can find a solution to this problem.

The Context object

When creating a web application, is is possible to introduce global information that should be accessible to all Java Servlets and JSP pages in the application. Such information can be found in the Context object. This object can be used to store global information in run-time, which is done by calling the "context.setAttribute(key, value)" method, where key is a String object and value can be any object.

The session object

When a user requests a page from a web application, a session is created and set up between the browser and the Java Servlet engine the first time a Java Servlet or JSP is accessed. When no accesses has been made between the client and the server for a specific amount of time, the session is

considered obsolete, and all object instances inside the session object for that session is thrown away inside the Servlet engine.

The Session object can, just like the Context object above, be used to store run-time data.

The request object

When a client accesses a Java Servlet instance, either the method "doGet()" or "doPost()" is called. A Request object is passed as a parameter to one of these methods. This object contains browser

information, such as the name of the web browser, and variables defined in the HTML page that linked to the Servlet. The Request object can also be used to store run-time data, using the

"request.setAttribute(key, value)" method, where the key is a String object and the value is any type of object. The object is passed to all pages included in the page being requested, where the other pages would be pages included using the <jsp:include> tag in a JSP page. The Request object exists during the access time for the pages, and is thrown away at the end of the request.

All of these objects above can be used to hold run-time information from Java Servlets and JSP pages. The best object to use for our specific problem would be the Request object, since it is automatically thrown away after a request is finished, and it is only shared between the called page and its included pages.

The complete solution

A small example of the include and object passing functionality is presented in this section. First out is a JSP page called "mainpage.jsp" that includes another JSP page called "name.jsp" and sends some information to it: <HTML> Welcome <% request.setAttribute("userName", "Joe"); %> <jsp:include page="name.jsp">

<jsp:param name="extraData" value="userName"> </jsp:include>

The text "Joe" in inserted in the request object using the key "userName", and then the page "name.jsp" is included inside the JSP page. The page "name.jsp" is presented next:

<HTML> <%

String key = request.getParameter("extraData"); String text = request.getAttribute(key);

%>

<B><%= text%></B> </HTML>

When calling the page "mainpage.jsp", the following output should be produced:

Welcome Joe

The example is maybe not that exiting, but it uses all the functionality needed to create more advanced dynamic views. The JSP pages could also communicate with the business logic using sub-classes of the PropertySource class, which is the object used in Gen templates that contains the dynamic content. Using the method above, it should be a rather trivial task to switch from Gen templates to JSP pages.

Conclusion

It seems that it is possible to use JSP templates to create dynamic views in thin clients. This statement is not empirically tested, but the key issues with creating dynamic views has been identified and theoretically solved. It might be interesting to implement it in the final prototype. The main reason for still using Gen is that it is tightly integrated with the CEL framework, and thus Gen fulfills our design goal of utilizing Caleigo's technologies as much as possible.