Sounds great, but I get really frustrated when I write JavaScript code that works fine in Firefox and Safari, but errors in IE. These errors usually result in hours of cursing and hair pulling, which lead me to believe that if Microsoft did not bundle IE free with Windows in the first place it would have never been the first browser anyway. Normal people do not really care, but for developers IE is a great pain. You either develop for IE or other browsers, or go to great length and cost to ensure your code works in at least IE, Firefox, Safari and may be Opera. The cross browser compatibility issue is hindering the adoption of browser based Rich Internet Applications that are based on JavaScript, DHTML and CSS. Many toolkits such as Dojo and ExtJS are compatible with many browsers, but you have to write your own JavaScript code which might not be compatible with all browsers.

I have faced two issues with IE where I pulled my hair for a while, but was glad to find some answers in Google before I ended up with no hair, apparently many other developers experienced the hair pulling over IE behaviour and if you feel the same you are not alone.

First problem: tr.innerHTML, I developed a nice piece of JavaScript that manipulates a table and dynamically create and delete table rows based on available data and user’s actions. Since I developed it in Firefox I used the innerHTML function to populate the table columns in the table rows, a piece of code that worked fine in Firefox, but failed miserably in IE, after some hair pulling and Googling the answer was you can not use innerHTML with TR in IE. You have to use the tr.deleteCell and insertCell functions I had to grow my code considerably to also work in IE.

Second problem: IE error message ‘Expected identifier, string or number’. I got this error message on some code that worked successfully in Firefox. And although the Microsoft Script debugger pointed me at the error location, I just could not see any problem with the code. A couple of hours of frustration and hair pulling I decided to search for the error message in Google and voila I found the answer it is to do with comma in the code below which will work successfully in Firefox, but fail in IE:

// private functions
/**
* @return window if found
* @param {Object} windowName
*/
var getWindow = function(windowName) {
var win = Ext.WindowMgr.get(windows[windowName]);
if(!win)    {
// create a new window
win = new Church.windows.addChurchWindow({
id: ‘add-church’,
});
if (desktopEl) {
win.render(desktopEl);
}
}
return win;
};
I think I left this comma in place by mistake after deleting a second line. Anyway I would not expect more from IE, I just wish everyone will be convinced to move away from IE and use Firefox or Safari, so we developers don’t have to go through the pain of developing for IE. And I also wish that IE would degrade gracefully in case of the issues mentioned above and many others.

SOHO routers are not designed for heavy use or to handle a large number of UDP connections usually required by VPN connections. This is a great pain for someone working from home and using VPN to connect to their company’s network. So cheap SOHO and ISP supplied routers tend to run very slow and drop the connections sometimes if they get overheated or if they have to handle many VPN or P2P connections. There is a good article on the ’slow running’ of routers on dd-wrt.com website. For me I’ve decided to ditch my router and look for an alternative, reliable and cheap solution.

Using a computer as a router seemed as a good idea at the time, after all SOHO routers have the following features:

• Microprocessors run at around 75MHz
• Have a number of RJ45 interfaces, at least one for WAN and one for LAN access
• Use IP Masquerading (NAT) to allow LAN computers to access the WAN using a single WAN IP address.

Now all the above features are achievable using a computer. I looked around and couldn’t find a 75MHz computer and I regretted throwing away my old 8086 Amstrad. Anyway I had a Pentium 1 233MHz MMX motherboard with a processor lingering around since 1998 so I decided to use it to build a computer and use as a network router. This is what I needed:

• Pentium 1 233MHz MMX motherboard with a processor
• 2 Network cards, one for WAN (Red Interface) and one for LAN (Green Interface)
• An old 5GB hard disk
• 256MB of memory
• An old VGA display adapter
• Some sexy neon lights and bio-hazard logo to spicen up things.
• Keyboard and monitor only needed to setup the OS, after that they can be taken away

For the operating system, using a lightweight Linux distro seemed like a good option, so searching around on Google I found two good Linux distros for firewall routers: SmoothWall and IPCop. Having briefly looked at the manual for both, it seemed like IPCop has most of the features I needed specially the ability to setup custom routing. I run two subnets with the traffic between them hitting the router, so the router needed to forward the traffic between the two subnets as configured, bearing in mind the router is not the gateway between these two subnets, I use a Fedora Core server for this purpose.

IPCop is basically a cut-down Linux destro with an Admin Web interface. There is no graphical interface, but remote login through SSH is available and can be switched on or off as required. There are so many other features available from the Admin Web interface such as Intrusion Detection, Traffic Shaping and Dynamic DNS, to mention only a few. Ever since it was installed, my IPCop Firewall Router is running effortlessly day-in and day-out without any issues so farewell routers.

Java Persistence API (JPA) coined with Java 5 Annotations made Object to Relational Mapping (ORM) a bliss. The problem is most of the detailed documentations available usually consider JPA from the POJOs perspective, but what if we are creating a JPA application that should persist to an existing database. An Entity Relationship diagram can easily be constructed for existing databases using a tool such as Toad Data Modeler. From the ER Model we can work backwards to create the JPA annotations required to presist to the existing database. This article provides a mapping that can be used to create the JPA annotations for an existing database’s ER Model using Hibernate’s implementation of JPA.

I prefer to use the crow’s feet notation in the ER model to represent the cordiality of the relations and the participation conditions as explained in Table 1 below. An example of an ER model that uses this notation is shown in Figure 1 below.

Table 1 – Crow’s feet notation used in the ER- modelling

Figure 1 - Sample ER Model using crow’s feet annotation

The approach that can be used to map relations form the E-R model into JPA annotations is summarised in Table 2 below. This approach can be followed to map the entity classes into the existing data schema using JPA annotations. Good database design should resolve all the Many to Many relationships during the logical database design stage by introducing a third dependent relation, and hence there was no need to use @ManyToMany JPA mapping.

I have also discovered that the Cascade annotation for foreign key updates on the parent table should not be included in the child entity as this will result in the deletion of the parent row whenever a child row is deleted. It was clear that this constraint should be implemented in the database schema and not included in the JPA annotation as it does not have the desired effect.

Table 2 – ER-Model and Relational Mode to JPA and Hibernate mappings

One approach to user interface design is the use of prototypes. Prototypes are incomplete versions of the user interface for the software being developed. Using prototypes at the early stages of requirement gathering and analysis helps in clarifying the requirements with the client and forms the starting point for the user interface design and implementation. In this article we look at the prototyping approach to user interface development for Rich Internet Applications.

User interface prototypes are usually developed to look informal, but yet functional. The problem with developing a complete GUI for prototype is the fact that it gives the client the impression that large parts of the development is already done and leads them later to question why the development is taking such a long time when almost all of the application was done during the requirement gathering. A good article on this is the “Don’t make the Demo look Done”, from Kathy Sierra’s blog. Below is an example of two user interfaces, one that looks almost done and the other one look extremely informal by using the Napkin look and feel for Java applications.

Figure 1. Prototype that looks almost done.

Figure 2. Prototype that looks informal

An established approach to software design is the use of the USDP (Unified Software Development Process). The main focus of the USDP is on modelling the business requirements using standards such as UML. This approach reinforces the focus on business first then technology, enabling the business model to exist independent of any platform or technology. The prototype is usually developed during the preliminary system design stage, which aims at providing an analysis model.

Requirement Capture and Modelling

Typical steps followed during the requirement capture and modelling stage are summarised below:

Techniques

1. Requirement elicitation using methods such as:

• Background reading

• Fact finding interviews with the client

• Observation

• Document sampling

• Questionnaires.

2. Use case modelling to be carried out and documented as follows:

• Use case diagram.

• Use case description

• One or more flow of events (i.e. Normal or baseline flow, alternative flows and exception flows)

• Activity diagram to aid the understanding of the use case. Activity diagrams are less technical than sequence diagrams so their use at such an early stage can aid the understanding of the business stakeholders.

3. Initial system architecture can be developed to help guide subsequent steps during the development process and can be refined and adjusted as the development process progresses. The initial system architecture is usually the package structure of the system.

4. Prototypes of some key user interfaces are to be produced to aid the requirement understanding and gathering.

Key Deliverables

• Use case model

• Requirements list

• Initial architecture

• Prototypes

Prototyping for the web

When developing prototypes for the Web a distinction have to be made be made between web sites and web applications. Web sites are mainly concerned about information; on the other hand web applications are concerned with tasks such as the steps involved in a process. This basic duality of the web was discussed by Jesse James in his book “The Elements of User Experience”. The web can basically be treated as a software interface or as a hypertext system and software developed for the web can categorised as either an application or a hypertext information space or a hybrid of the two. In this article I would use the term websites to refer to applications that utilize the web as a hypertext system and the term web applications to refer to applications that utilize the web as a software interface or a hybrid of both.

Based on new concepts such as Web 2.0 I will go a step further and divide web applications into two categories:

1. Traditional web applications based on web pages where the progress in the application is largely based on form submission or Hyperlink navigation to post or retrieve data/contents from the server.

2. Rich Internet Applications based on using AJAX or some other technology to submit or retrieve data from the server without having to use forms or submit a whole page. These applications resemble desktop thick clients in their interactivity, responsiveness, flexibility and rich user interface. RIA can be divided into two types:

   • In-Browser or browser based – These utilize the browser capabilities such as HTML, JavaScript, CSS and XMLHTTPRequest.

   • Out-of-browser or plug-in based – These utilize the capabilities of external plugins such as Adobe AIR, Microsoft’s Silverlight and JavaFX from Sun.

Prototyping for traditional web applications:

For traditional web applications prototyping can be done using paper or computer based wire-frames. Microsoft Power Point, Visio or Open Office Impress can be used to construct these wire-frames; in fact any image authoring tool can be used to draw up a prototype. But such prototypes are simply static and lack the interactivity. DENIM is a tool that can be used to create prototypes for websites and web applications. Such prototypes do look informal and can be designed to have some elements of interactivity.

Figure 3. DENIM prototype for web application

Prototyping for RIA

As Rich Internet Applications closely resembles traditional desktop applications there is nothing that stops us from using the same prototyping methods used for the desktop clients to design prototypes for RIA. The user interface for RIA runs entirely on the client side, but the UI is first transferred from the server to the client upon first request. For subsequent requests the client only exchanges data with the server. RIAs now benefit from a large number of rich widgets that sometimes look even better than widgets available for traditional thick clients; this analogy between these two types of applications is shown below.

But before starting to prototype for RIAs we probably need to have a catalogue of currently used visual widgets such as controls, commands, pointers and windows. A good starting place is the Visual Index on the Microsoft Window Vista User Experience guide . We can then short-list the widgets that can be included in the prototype and the completed user interface later on.

Figure 4. Analogy between RIA and thick clients

Many tools can be used to prototype for RIAs, I personally prefer using the NetBeans Swing GUI builder but you can also use other Visual IDEs such as Visual Basic IDE. NetBeans GUI builder is based on Java Swing so the Napkin look and feel can easily be integrated to create informal prototypes. The builder has a good size palette of widgets such as tab containers, grids, panels, buttons ,etc…

Figure 5. Swing UI builder

Prototype Example

Below is a prototype developed for a window that deals with the user’s tasks. Each user has a number of tasks that they can view; the user can refresh all the tasks, delete a task or set a task as completed. The prototype was first developed in NetBeans builder then exported to Paint to customize the look and feel of the action buttons.

Figure 6. Modified Swing GUI for tasks window

Below is the use case diagram for the view tasks use case.

Figure 7. Use case diagram for tasks requirements

Choosing the user interface development toolkit

You could write HTML, JavaScript and CSS to create a RIA, but this will be time consuming and why invent the wheel when there are many free toolkits and frameworks out there with many features to offer. Below is a summary of the widely used toolkits/frameworks to develop the user interface for Rich Internet Applications

User Interface Design using MVC

Below I will explain the implementation of the prototype in Figure 6 above into a fully fledged user interface using the Dojo Toolkit and the MVC pattern. The dojo toolkit streamlines JavaScript development by providing custom rich widgets, many utility functions and an Ajax library. JavaScript can be used as an object oriented language based on prototyping, the dojo toolkit provide a Java like style to defining objects and inheritance in JavaScript.

Figure 8. Client side MVC GUI

Widget objects defined in Dojo can also have a HTML template and linked to DOM nodes. The widget object then manipulates the HTML nodes to display information or responds to user actions such as button clicks, etc….

A new approach to web user interface development

The approach I have followed here to develop the rich HTML user interface is not widely used for web applications, although the process used is deeply rooted in the USDP and was used for a long time to model user interface for desktop applications developed in languages such as Java and Visual Basic. Saying this, the fact that JavaScript supports object orientation, there nothing that prevents us from using the same methodology to design the user interface for rich internet applications. These steps are based on the methodology outlined by Bennett et al in their book “Object Oriented Systems Analysis and Design Using UML”:

• Prototyping the user interface.

• Designing the classes.

• Modelling the interaction involved in the interface using interaction or communication diagrams.

• Modelling the control of the interface using state machines for complex UI components.

View – Presentation (HTML, CSS and DOM objects)

The view on the client side user interface is created either as HTML or JavaScript Widgets. HTML view is created when widgets are not required to provide functionality depending on user input or when it’s owned by a JavaScript Widget. On the other hand JavaScript widgets are used for complex user interface components such as widgets that control other widgets to perform a specific operation as shown above for the “My Tasks” widget.

Each JavaScript widget consists of the following:

1. JavaScript object, I use the term View Support Object (VSO) to describe these JavaScript Objects as they control the DOM nodes attached to them (Figure 8).

2. DOM nodes to represent the HTML template for the widget.

3. Can also include other child widgets as widgets can be nested.

For each view component the view is implemented using this widget approach as follow:

• Define the widget template which consists of HTML, CSS and other widgets, this is defined in a HTML file e.g. manageTasks.html.

• Define the VSO for the widget in a JavaScript file, e.g. manageTasks.js using a JavaScript class definition from the Dojo toolkit as follows:

To define a widget class (supports Mixins, multiple inheritance): dojo.widget.defineWidget(”ClassName”, [SuperClass1, SuperClass2, …], { property1: “”, property2: “”, method1: function() { // method code here } } To define a non-widget class (supports Mixins, multiple inheritance): dojo.declare(”ClassName”,[SuperClass1, SuperClass2, …], { property1: “”, property2: “”, // acts as a Java constructor initializer : function(urls) { this.urls = urls; this.user = “”; this.ajaxTimeOut = 600; // 600s, 10mins to wait for ajax // calls }, method1: function() { // method code here } }

Listing 1. Dojo classes declaration

• Implement the methods required for the VSO to control the DOM nodes. These methods follow from the user interface models such as boundary classes and interaction diagrams as shown in the diagrams below. For the ManageTasks widget a boundary class diagram and an interaction diagram was developed to detail the functionality of the ManageTasks JavaScript widget. If I treat JavaScript as Object oriented language then there is nothing that stops me Modelling Java alongside JavaScript Using a UML CASE tool as shown in the sequence diagram below showing client and server side objects. JavaScript built-in types can also be modelled using a js.lang namespace or package, the same applies to the classes provided by the toolkit being used.

Figure 9. Modelling JavaScript using UML

Figure 10. Boundary Class Diagram for ManageTasks Widget

The sequence diagram below demonstrates the modelling of server and client components together. The blue object denotes client side JavaScript object whilst the green one symbolise the server side classes. As shown the call queryAll is an asynchronous (AJAX) call as symbolised by the open arrow message and the queryAllTasksLoad call the call back method provided for AJAX response

Figure 11. Sequence diagram for View Task use case on the ManageTasks widget

Model – Data

Using JSON the server side domain model can be serialized and transferred to the client in JSON format, it will then be build into client side JavaScript objects using the eval method. This way the model on the client side will reflect the objects on the server side and there is no need to create class definition for the model on the client side.

An example is the sequence diagram shown above, the server side object TaskWrapper is serialized into JSON format and delivered to the client side, so the same object graph will also exist on the client side. The main advantage of this approach is the fact that there is no need to maintain two sets of class definitions for TaskWrapper on the client and server side, as the server side definition can be used in both layers.

Controller

The controller orchestrates the view, the model and facilitates communications with the server to retrieve/save data using Ajax. The controller does the following:

• Holds reference to and controls all the JavaScript widgets.

• Queries data from the server using Ajax and reconstructs the response into JavaScript model objects.

• Saves data to the server from the updated model.

• Enforces security and authorisation on the client side. The same enforcements are done on the server side to ensure no JavaScript tampering was done.

The controller can be programmed to use the JavaScript prototype or the dojo.declare to inherit from a generic controller class, which defines common functionality such as dirty flags, etc…. The controller can have methods such as: Show, Hide, Delete, Create, Save, Retrieve, etc…

The Final User Interface

The final user interface for the task management window is shown below:

Figure 12. The data is loading using AJAX

Figure 13. The data is loadedand displayed

References

• Arrington, C.T. and Rayhan, S.H. (2003). Enterprise Java with UML. 2^nd ed. Wiley

• Bennett, S. McRobb, S. and Farmer, R. (2006). Object-oriented systems analysis and design using UML. 3^rd ed. London: McGraw-Hill Companies.

• Bennett, S. Skelton, J. Lunn, K. (2004). Schaum’s Outline UML. 2^nd ed. McGraw-Hill.

• Dojo Ajax Toolkit. URL: http://dojotoolkit.org/

• Dojo Toolkit Object oriented concepts and inheritance. URL: http://dojotoolkit.org/book/dojo-book-0-4/part-3-dojo-programming-model/object-oriented-concepts-and-inheritance

• Gadge, V. Technology options for Rich Internet Applications. URL: http://www-128.ibm.com/developerworks/library/wa-richiapp/

  [16 September 2007]

• Garrett, J. J. (2002). The Elements of User Experience: User-Centered Design for the Web. New Riders Press.

• JavaScript Object Notation. URL: http://www.json.org/

• O’Reilly, T. What Is Web 2.0, Design Patterns and Business Models for the Next Generation of Software.
  URL: http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=1

[16 September 2007]

]]> http://dawelbeit.info/2008/03/09/web-user-interface-from-prototype-to-implementation/feed/ http://dawelbeit.info/2008/03/05/future-of-the-web-2/ http://dawelbeit.info/2008/03/05/future-of-the-web-2/#comments Wed, 05 Mar 2008 22:05:00 +0000 admin http://dawelbeit.info/2008/03/05/future-of-the-web-2/ It’s been quite an exciting journey for the Internet from being a hypertext medium to being an interface for deploying software applications. But there is still that confusion between websites, web applications and rich Internet applications, a confusion rooted in the duality of the web and the emergence of new technologies that enable a wide range of functionality and applications.

The term Web 2.0 is widely used these days to point to a range of technologies enabling some amazing things. Developers, reviewers, analysts and organisations all excited about the new web, people are even talking about Web 3.0 “Semantic Web”. There is a great deal of hype surrounding the web these days and a lot of promises, however there is a lack of clear strategy or consistent methodology for building applications for the new web

Different organisations are trying to come up with a toolkit, framework or a methodology to cash in the users’ excitement. In spite of all this the web will definitely continue to grow and who knows what the future of the web will hold…