Community
Participate
Working Groups
GEF's UndoablePropertySheetEntry defines private void createChildEntries() { // get the current descriptors List descriptors = computeMergedPropertyDescriptors(); // rebuild child entries using old when possible childEntries = createChildEntries(descriptors.size()); for (int i = 0; i < descriptors.size(); i++) { IPropertyDescriptor d = (IPropertyDescriptor)descriptors.get (i); // create new entry UndoablePropertySheetEntry entry = createChildEntry(); entry.setDescriptor(d); entry.setParent(this); entry.setPropertySourceProvider(propertySourceProvider); entry.refreshValues(); childEntries[i] = entry; } } protected UndoablePropertySheetEntry createChildEntry(){ return new UndoablePropertySheetEntry(); } This allows one to subclass UndoablePropertySheetEntry and override createChildEntry to create instances of your subclass. This same pattern should be used in Eclipse's base PropertySheetEntry so it can be easily subclassed and all children be created with the subclass' type. Currentlt, this is not possible, as its createChildEntries() method is private and doesn't use the factory method pattern to create the actual child instances.
Created attachment 13944 [details] PropertySheetEntry with protected createChildEntry() method This is an example of using template method and factory method to allow subclasses of PropertySheetEntry. Such subclasses can be used to allow custom sort order by prefixing the property display names as outlined in http://javadude.com/eclipse/sortingpropertysheetentries.html.
Created attachment 17892 [details] Patch to make PropertySheetEntry extensible This patch can be applied against HEAD to make PropertySheetEntry extensible (i.e. for the GEF undoable property sheet entry)
Created attachment 17893 [details] Patch to make PropertySheetEntry extensible This is a new version. (I accidentially hit the code formatter before).
Created attachment 17894 [details] Patch to make PropertySheetEntry extensible New version to address the GEF use case completely
Patch applied, thanks Gunnar. Is the createChildEntriesArray(int) method really necessary (I've already asked Randy in bug 39243)? I can't imagine why someone would need to override the array type.
I've cleaned up the Javadoc for the affected methods a bit too.
*** Bug 39243 has been marked as a duplicate of this bug. ***
Re comment #5, Randy responded with: > That makes sense to me. Perhaps that's an artifact of having copied the entire class at one point. So I will remove createChildEntriesArray(int) unless someone screams.
Randy and Scott, I'd appreciate if you could verify this for M6 (this is our API freeze milestone).
Looking at the patch (but not applying it), it looks good to me. Hits the things I wanted. Thanks much! I agree that the createChildEntriesArray(int) isn't needed. Thanks for taking care of this! -- Scott
Verified in I20050331-0800.
