Motivations

The first question I guess you have by reading this page is: there are already so many web framework around, why building one more?

The answer is quite simple: the WFNM framework is not just another web framework which competes with other web frameworks like Struts and JavaServer Faces.

Instead, it tries to solve problems which they do not solve and it has been originally designed to be used in conjunction with other web frameworks or even with servlets and JSPs.

There are at least three big issues which are not well archived by actual web frameworks and that are strictly tied each other:

Furthermore, the WFNM framework provides the following capabilities:

  • Avoid multiple form submits
  • Transparently add the "no cache" header directive
  • Log statistics about http session size

Webflow definition

A cool functionality that is often useful when designing a web application is the ability to split it into several parts.

For example it is usual for a web application that some parts of it are called by different web pages: when the part of the web application ends, the navigation should return to the calling page. Given that the calling page is not always the same, some mechanism should be used in order to remember which the calling page is.

This can be simply archived by the WFNM framework, which allows to label the caller part of the web application and the called part of the web application as two different webflows, allowing to easy backward navigate the web application during the called webflow by returning to the caller webflow (i.e. the previous webflow)

The ability to define webflows is a prerequisite for allowing a server side navigation history of webflows (see below).

Server side navigation history

The client side navigation history provided by browsers is not appropriated to backward navigate a web application. The WFNM framework proposes a different approach: keeping server side the navigation history.

The WFNM framework allows to keep a server side navigation history of visited web pages and webflows, providing information that allows some dynamic navigation facilities:

  • Back to the previous page
  • Back to the previous webflow
  • Back to a specific previous webflow given its name
  • Reload the current page

Also, it allows to keep the web application informed on which web pages and which webflows has been visited during the navigation, providing other useful information:

  • Has been a page visited during the current navigation?
  • Has been a webflow visited during the current navigation?
  • Which is the name of the current webflow?
The server side navigation history is also a prerequisite for allowing automatic session cleaning (see below).

Automatic session cleaning

A best practice for the development of a web application is to keep small the size of the http session. Especially for banking applications the amount of information that is usually kept into the http session is huge.

The time-to-market for the development of web applications is becoming every day more and more important, and usually developers do not have time to check that objects are removed from the user http session when they are no more necessary.

A structured approach for automatically cleaning the http session is much more appropriated than hoping developers have time to implement this kind of "optimization".

The WFNM framework provides different policies for automatic session cleaning when returning to a visited page/webflow. By default, the WFNM framework removes every object that has been placed into the http session during the navigation of a webflow when it is closed (i.e. when returning to a previous webflow).