ZXAF Views and Forms problems [resolved]

This has now been resolved with the new views that arrived in r11; however I'm keeping the page because it is a good indicated of middle aged code spread

Currently we have the view-main module; however we have developed into a situation where there are two different methods for presenting form and or table view (for display and/or edit).

So, we have ViewItems and FormFields, and they are needlessly different as their work and function is very similar; the major difference being that FormFields are currently much more closely tied to the DB entities, and as such can directly update values; whereas ViewItems merely have an ID and expect not to be able to modify their data (in this sense a View is originally Readonly, whereas a Form was always intended to allow modification of elements).
This stems from the way that the view module has been built by refactoring existing working code and we really need to fix this sensibly.

A form is created as follows:

$fields = array();
$validator = new ValidateFieldRequired($edit_buttons);

$ffp = new FormFieldProvider($edit_buttons);
$fields = array();
$form = new Form("form1", $fields,"Details","HelpSite Details","admin/helpsite");

$form->add_field ( new FormField($si, "Category", "category", $validator, $ffp));
$form->add_field ( new FormField($si, "Section", "section", $validator, $ffp));
$form->add_field ( new FormField($si, "Topic", "topic", $validator, $ffp));
$form->add_field ( new FormField($si, "Help", "help", $validator, new HtmlEditorFormFieldProvider ()));

It is processed as follows:

$entity = new CbfEntity();
$form = make_form($entity);

if ($form->ajax_process($entity))
    return;

This is fairly clean and quick, although the Form constructor needs rationalizing to remove the quantity of fields it is tolerable.
Each form field must be constructed with a FormFieldProvider derived object. This object is used to define the way that the form field operates.

For displaying lots of data (from an iterator) we use a TableView, which is more developed than the Form, however it's not as good at editting: typical use of a TableView is as follows:

$tv = new TableView('id');
$col = &$tv->add_column("user","UserID");
$col = &$tv->add_column("type","Type");
$col = &$tv->add_column("date","date");
$col = &$tv->add_column("table","Item");
$col = &$tv->add_column("actioncode","Action");
$col->set_output_transform(new ViewItemTransformHtmlSpecialChars());
$col = &$tv->add_column("ipaddress","IP");
$col = &$tv->add_column("additional","Details");
$col->set_output_transform(new ViewItemTransformDetails());
echo $tv->get_output(new CbfDbIterator());

Internally the view works closely with the iterator and the db_entity. By default the value of the field specified in add column (param1) is merely output, however we have the concept of an output transformation, which is very useful as it is an object (derived from ViewItemTransform) that will be responsible for preparing the value for output (the output is still done by the class).
The output transformation can be used in a simple case to format decimals, however it can also lookup values from other tables, and substitute names for ids etc.
Also output transformation objects may be chained by passing an output transformation object to the constructor.