11/2/2014 1.41

• Scroll gestures on iOS and Android.
• AJpaDataGridModel.getCollectedValues() to collect all values in a column, useful for excel like filtering. Better in memory filtering support (setFilterInMemory()).

  for a list of changes

20/3/2012 1.33

• A field can now change its value while self-validating. Used by AFormattedTextFieldWithChoiches to change its value when the selectable-values list changes and the current value is non admitted any more.
• IPojoForm.getPojoVersion() any time it changes a new pojo has been provided to the form, which means that form fields have been re-initialized.

  for a list of changes

13/09/2011 - IFW2 1.31

• OnDiskChunckedList greatly improves memory handling for large AJpaDataGriModel. It is used by default when paging is active.

  for a list of changes

21/07/2011 - IFW2 1.30

• IColumnGroup to group-up columns on ui grids.
• APojoCrossModel and cell-cursor on DataGridFlow.
• Usability: place a button on an editing calendar or lookup field.
• Initial support for Motorola Xoom Android Tablet.

  for a list of changes

26/04/2011 - IFW2 1.29

• IFormValidator2.begin(...) can return false to exclude the validator from the current validation cycle. Breaks compatibility with the past.
• Added support to tinyMCE integration. howto
• Added precompiled jsps for Tomcat 7 under then net.infordata.ifw2.web.jsp7 package.

  for a list of changes

22/03/2011 - IFW2 1.27

• Added support for IE9 and FireFox 4

  for a list of changes

20/01/2011 - IFW2 1.25

• AJpaFolderModel deep-search.
• DialogBoxFlow can now have predefined icons using DialogIconEnum.
• JpaUtil.fetchAll(...) methods usable to ensure fetching of all metamodel properties from db, collections included.

  for a list of changes

all news

Flow

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:

• A state of another flow, becoming a sub-flow. The parent flow is blocked until the sub-flow terminates and its execution can depend on the sub-flow ending state.
• As a modal dialog, the whole application or a portion of it (it depends on the usage of a unique main flow or one of them for each application group of functionalities) is blocked, waiting for the flow termination which triggers the execution of call-back code.
• As a flow component, i.e. the flow is active while its parent flow is active (with all of its flow components).

  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.

  

Event delivery phase

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:

• Form posts including multipart forms for file uploads (with a progress bar)
• User action which can be triggered by buttons, html links, keyboard, mouse and focus change.

  Keyboard and mouse events are bindable to forms, single html events or form fields and can generate server-side events or client-side events.

• Field changed events which can trigger data validation.
• …

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.

Rendering phase

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:

• Memory consumption on the server side.

  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).

• Browser incompatibility.
• IE memory leaks.
• Focus handling after user interface refresh
• …

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.