Bug 257767

Description Zack Roadhouse 2008-12-05 16:00:06 EST

Build ID:  I20080617-2000

Steps To Reproduce:
It is extremely difficult for developers to customize the look and feel of mulitpage editors because of the design of the MultiPageEditorPart class.  The following issues contribute to this difficulty:

1) The container for the MPEP is a CTabFolder, which cannot be extended

2) Methods that access/modify the container all use specific CTabFolder functions

3) Many of the methods that access/modify the container are private and cannot be overwritten in subclasses of MPEP

It appears that the designer did intend to allow the user to specify a different container because the getContainer() method returns the more generic type Composite instead of a CTabFolder.  However, in this implementation only a CTabFolder will ever be returned.

Our solution - In order to work around these constrictions, we created a subclass on MPEP.  This subclass defines a new  method createContainer() that disposes of the CTabFolder and assigns our own custom tab folder to the container field.  Then  all private methods that access the tab folder (createItem(), getItem(), disposePart(), etc.) and any public or protected methods that call these methods essentially were copied into our MPEP subclass to ensure the correct container was being  used.  This results in over 300 lines of essentially duplicate code between the MPEP class and our subclass.

Long term solution - In order to make it easier for users to customize the look and feel of the MultiPage editors, the following changes could be made:

1) Allow CTabFolder to be extended, or create an interface for tab folder objects that specify required functionality

2) Allow the user to pass in their own tab folder object to the MPEP constructor to be used as a container for the MPEP

This way the user's custom container can be used without having to duplicate the methods the try to access or modify it.


More information: