Customization of the field handling within views
Motivation
One of the long-term goals of the PIM development team is to eliminate the necessity to override the standard views in order to put some custom "business logic" to the existing views. Instead of this it should be possible to affect the standard views "from outside". As first step for this approach we created a new extension point which can be used to customize some field based logic of the standard views.
Extension point
The new extension point "fieldBasedTableViewExtensions" allows to influence the field handling of the standard views. For that reason the extension point provides the element manager:
You can contribute a FieldBasedTableViewExtensionManager for a view class or for a view ID. On the view creation the corresponding FieldBasedTableViewExtensionManager will be searched. First we search for a manager contribution for the view ID, if nothing found - for the view class. So if your FieldBasedTableViewExtensionManager is more specific for only one particular view, then define the view ID in the manager contribution. If the manager should be used for all derivations of a view - use the view class attribute instead. Additionally you can define the rank of your FieldBasedTableViewExtensionManager. If there are several manager contributed for the same view ID or for the same view class - the one with the highest rank will be used. All standard implementations of FieldBasedTableViewExtensionManager have the rank "1". So use a higher rank if you want, that your manager is used instead. Each manager contribution should define a unique id, so that it can be disabled by using the activities (see also Possibility to disable standard UI elements).
Availability
This extension point is available since PIM version 7.1.01.00 (see also the corresponding JIRA issue: 
HPM-17694 - Projectrequest: extension point to customize the field handling in a view Closed
)
View extension manager implementation
In order to provide a possibility to change the field handling of the standard views, the FieldBasedTableViewExtensionManager provides a lot of methods which can be implemented in the custom manager. There are already some standard implementations of the FieldBasedTableViewExtensionManager for a number of views:
For all FieldBasedTableViews the default implementation of the manager is used: FieldBasedTableViewExtensionManagerBaseImpl. You can also extend the standard manager implementations and put your custom code. All the standard FieldBasedTableViewExtensionManager implementations are located in public packages, so you can use them in your customizings. An example of a custom implementation of FieldBasedTableViewExtensionManager you can find in SDK example plugins: sdk\examples\customizing\com.heiler.ppm.customizing.ui --> CustomAccumulatedAttributeTableViewExtensionManager
TableCellValueProvider
By defining your own TableCellValueProvider you can affect the getting resp. setting of the field values in the table view as well as define whether a specific field value can be modified by the user. To provide your custom TableCellValueProvider implement the method createTableCellValueProvider( TableCellValueProvider decoree ) in your FieldBasedTableViewExtensionManager. The default implementation of the just returns the decoree parameter without any modifications:
@Override public TableCellValueProvider createTableCellValueProvider( TableCellValueProvider decoree ) { // just return the given value provider return decoree; }CellEditor
Sometimes it is necessary to provide an other CellEditor for a specific field in the view them a standard CellEditor. Usually the standard CellEditors are created in a generic way by using the FieldBasedCellEditorFactory dependent on the field datatype. So if the corresponding manager returns null the standard CellEditor will be used:
@Override public CellEditor getCellEditorForField( Composite parent, Field field ) { // return 'null' by default return null; }ICreateMechanism
If you want to change the dataset creation process of a view, then the method getDatasetCreationMechanism() of the FieldBasedTableViewExtensionManager is the right place for it. The default implementation of the manager returns null. If no other manager implementation for the view is registered, then the default creation mechanisms will be used: so the ListModelTableViewCreateMechanism for all list-model views and the EntityDetailModelTableViewCreateMechanism for all detail model views.
IDoubleClickListener
If the user clicks into an editable cell, the CellEditor will be activated, but - if the cell is not editable - we are able to add a double-click listener to the table to define, wath should happen. As default for all FieldBasedTableViews we provide a double-click listener which shows a simply dialog with the content of the clicked cell. This is usefull for all not-editable fields, since this allows the user to select and copy the field value (which is usually not possible within the table):
@Override public IDoubleClickListener getDoubleClickHandler() { if ( this.tableView instanceof FieldBasedTableView ) { return new DefaultFieldBasedTableViewDoubleClickListener( ( FieldBasedTableView ) this.tableView ); } return null; }Another advantage of this behavior: if the cell content is very large it is hard for the user to read it within the table. Now with a double-click the user can open a read-only dialog with a multi-line text field and can read the whole text:
