First of all we invite you to take a look at the live demo of what you can achieve by using this framework.
Keep in mind that the demo is currently hosted on a system with no guarantee about availability so, if it is not ready at the moment, please be patient and try later or download the last distribution which includes it (see how to setup the sample application).
To properly use the demo you need one of the supported browsers which are:
At the end, for the programmer, it is composed by a few classes/interfaces, a tag library and some fixed entry to be included in the "web.xml" file.
The tag library is bindable to the application data model through a predefined set of interfaces in a way, conceptually, similar to the Swing library.
Some "complex" flows are provided and ready to be used, such as DataGrid and TreeGrid. They interact with the model via interfaces in a way that looks like Swing. Default implementations of those interfaces are included
You can think about Flow as a self-contained and reusable controller module.
It is designed to represent user interaction as a finite state machine.
Each flow can be in turn used as:
This allows you to model reusable components as flow.
A flow component can publish events to its parent which can react by "stimulating" child components.
Think about a flow component as a "light portlet" if you like.
During this phase the flow engine has the responsibility of distributing the user input and the user interface events to the right flow (whatever is its usage, sub-flow, modal-dialog or flow-component, in ifw2 terms called personalities).
In order to do it the resulting html page is automatically "instrumented" with hidden info inserted by the ifw2 tag library (yes, you have to use it in your jsp).
Moreover, each flow and its relevant contained html elements, form and form-controls have a scoped id to prevent id collision when used with other flows in the same page (this is a very common situation with ifw2, think about flow-components for instance).
The following is a list of delivered user inputs and user interface events:
Keyboard and mouse events are bindable to forms, single html events or form fields and can generate server-side events or client-side events.
Everything happens by the usage of ajax call (except for file upload which uses an hidden iframe).
Once a flow receives and elaborates the event, which can lay to data-model update or can cause a state switch of the flow itself (and possibly of its parent flow), the rendering phase starts.
Starting from the main flow (each page/url can have its own but in many cases there will be one for application) or better, from the renderer of the main flow (usually a jsp), recursively walk through the hierarchy of "included in the current view" flows and contained delimited (via tags) page regions and build a tree of "content parts".
Compare the tree to previously delivered content tree to find out which nodes are changed, removed or added.
Take the top most ones only and return them to the client side rendering engine that will update the browser page.
This phase is quite simple to describe but not very simple to be implemented, think about some of the issues ifw2 has to deal with:
Ifw2 limits it by storing for each content part just its md5 signature ready to be compared with the new one when needed, removed nodes are immediately discarded.
It is quite easy to swap not visible flows to a secondary memory location via cache mechanisms (very likely a future version of ifw2 will include this functionality directly).
If you think about other ajax based frameworks here the interaction between the client and server side is, for the final programmer, greatly simplified.
He just has to think about producing html code via jsp and the ifw2 rendering engine will deal with the rest.
The ifw2 rendering process is, by the way, a sort of porting of desktop application paint process to the web.