Bug 201223 - API for using custom property editors without PropertySheet
API for using custom property editors without PropertySheet
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Explorer
7.1
PC Other
: P2 (vote)
: 7.1
Assigned To: Tomas Pavek
issues@platform
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-22 16:22 UTC by Tomas Pavek
Modified: 2011-09-01 14:21 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
proposed change (19.33 KB, text/plain)
2011-08-22 16:29 UTC, Tomas Pavek
Details
updated patch (19.41 KB, text/plain)
2011-08-23 14:58 UTC, Tomas Pavek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Pavek 2011-08-22 16:22:43 UTC
For integration with JDev there is a need to use the node properties and property editors from NB without the PropertySheet or PropertyPanel UI. I.e. be able to reuse the property editors (e.g. for painting the values), and also the components for custom editing. For that I need to support two new uses cases in the API:

1) Be able to explicitly create a PropertyEnv instance so it is possible to initialize ExPropertyEditor instances independently on PropertySheet.

2) Be able to explicitly invoke the custom editor dialog for a property just like it is invoked by the property sheet (including writing the value back to the property when the dialog is successfully closed via OK).
Comment 1 Tomas Pavek 2011-08-22 16:28:54 UTC
Here's a suggestion how to implement it, see also the attached diff.

ad 1) Simply add a static method to PropertyEnv that creates a new instance.

ad 2) It seems NodeOperation in openide.nodes (implemented in openide.explorer) already does similar things, so could be extended with one additional method. The implementation just requires some ugly bridging code to actually invoke the package private CustomEditorAction with equal Invoker implementation as used in SheetTable. Added a simple test that the bridging works.
Comment 2 Tomas Pavek 2011-08-22 16:29:49 UTC
Created attachment 110138 [details]
proposed change
Comment 3 Jesse Glick 2011-08-22 17:36:42 UTC
[JG01] Look out for rawtype warnings in public method signatures (like Node.Property rather than Node.Property<?>).


[JG02] Varargs would be useful for 'beans' parameters, since they are usually length=1 arrays.


[JG03] Should not add an abstract method to NodeOperationImpl; provide some fallback impl, or create a subclass with the added abstract method.
Comment 4 Tomas Pavek 2011-08-23 09:08:34 UTC
> [JG01] Look out for rawtype warnings in public method signatures
> (like Node.Property rather than Node.Property<?>).

OK, good catch, will add <?>.

> [JG02] Varargs would be useful for 'beans' parameters, since they are
> usually length=1 arrays.

Right, forgot about that.

> [JG03] Should not add an abstract method to NodeOperationImpl; provide
> some fallback impl, or create a subclass with the added abstract method.

You mean not to add abstract method to NodeOperation. True if NodeOperation can be implemented by someone else than openide.explorer (isn't that only hypothetical?). Anyway, I can make the method non-abstract, but there is no good fallback. It would be noop or throw UnsupportedOperationException.

As for creating a subclass, I did not want to introduce a new API class just for the showCustomEditorDialog method, that's why I added it to NodeOperation. Otherwise it would fit better directly to org.openide.explorer.propertysheet package. (I would add it there if there was some public class with static utility methods.)
Comment 5 Tomas Pavek 2011-08-23 14:58:07 UTC
Created attachment 110160 [details]
updated patch
Comment 6 Jaroslav Tulach 2011-08-25 10:52:21 UTC
> I can make the method non-abstract, but there is no
> good fallback. It would be noop or throw UnsupportedOperationException.

A dummy implementation would be better than no impl. Users of the API could then rely on some implementation being always present. 

The most simple operation I can imagine is to show a dialog with single input line and OK/Cancel button. The input line would be filled by 

ed = property.getPropertyEditor();
ed.setValue(property.getValue());
textLine.setText(ed.getAsText());
if (!property.canWrite()) {
  textLine.setEnabled(false);
}

user could edit the text. If OK is pressed, then 

ed.setAsText(textLine.getText());
property.setvalue(ed.getValue());

would be used to fill the value back. Nothing magnificent, but better than UOE.
Comment 7 Tomas Pavek 2011-08-30 11:44:14 UTC
The dummy implementation of showCustomEditorDialog would be hardly usable except quite trivial cases. And I think its not really needed since there is no "default" implementation of NodeOperation, only the one in openide.explorer. So I'm going to keep it throw UOE.

Thanks for the review, I'm going to integrate tomorrow.
Comment 8 Tomas Pavek 2011-09-01 09:05:03 UTC
Done.

http://hg.netbeans.org/core-main/rev/5ecbc4726e74
Comment 9 Quality Engineering 2011-09-01 14:21:48 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/5ecbc4726e74
User: Tomas Pavek <tpavek@netbeans.org>
Log: #201223: new API PropertyEnv.create and NodeOperation.showCustomEditorDialog


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo