Created attachment 133932 [details]
proposed api change + test

attaching the proposed change, including the API changes, change in j2seproject CustomizerProviderImpl and a test. The actual use of the modified CustomizerProviderImpl is not yet available as it is part of more complex changeset that would not make sense here.

MK1: the current implementation just closes the dialog. Is the intended behaviour to be equal to Cancelling the dialog? If so, maybe the documentation should be  explicit about it, or maybe even the method name should be changed to make it obvious.
MK2: related to MK2. ProjectCustomizer.createCustomizerDialog() method is passed the storeListener and okButtonListener ActionListener instances that get called when user clicks ok on the customizer. Similarly individual panels can add ActionListeners via ProjectCustomizer.Category (close/ok/store).
How do these listeners interact with the newly introduced method. Will they be called?

DK1 - would it make sense to do this change directly in projectuiapi instead of java.api.common? And fix with it also issue 154676? That would help me a lot. :-)

ad MK1 and MK2 - our use-case is to close customizer as if user pressed Cancel. The OK and Save listeners indeed are not called in this way. You are right we need to describe this more explicitly in docummentation.
As for the question whether to support closing with invocation of OK and Save listeners - we have two reasons for not doing it at this moment: 1. we do not need it, 2. the ways how to implement it are not straightforward and would require further changes in the API that would make the whole thing less clear. Currently ProjectCustomizer.createCustomizerDialog() returns a Dialog, in which OK and Cancel buttons are programmatically created and listeners attached to them - there is currently no way of invoking them from outside the Dialog. Solutions would be: either extend the API further, to enable registering callbacks with CustomizerProvider3, to be called from a place where the OK and Save listeners are still known (in this case from CustomizerProviderImpl), or by creating a wrapper to Dialog that would have listener accessing methods, these would however not be accessible in context where the dialog is referenced as Dialog only...

ad DK1 - the problem with placing it to projectuiapi is the fact that CustomizerProvider3 extends CustomizerProvider2 which resides in java.api.common. We would have to move both CustomizerProvider3 and CustomizerProvider2 to projectuiapi what is possible, but would have implications in lots of code that would subsequently need to be updated. This is a problem at this moment and will need to be postponed to future more complex code polishing effort (which is indeed considered for future as I was told by Tomas Z).

re DK1 - I hope that CustomizerProvider2 will move to projectuiapi in 7.4 timeframe. It would simplify some other new APIs which were are creating for 7.4. Depending on the time I would like to submit a patch which does the change and updates SE/EE project types. Should be relatively small change. That would result into deprecation of CustomizerProvider2 in java.api.common. In that light I suggest that your CustomizerProvider3 extends directly CustomizerProvider to avoid depending on soon to be deprecated class.

re MK1 and MK2 - (my two cents) the workflow does not sound very logical: user did a change in Project Properties and the change needs to close the Project Properties dialog and so you call closeCustomizer() to "cancel" all changes done in Project Properties. If it is really rarely used action why not to just show in UI "changes will be visible upon reopening project properties dialog" and let user do that.

(In reply to comment #5)
> re DK1 - I hope that CustomizerProvider2 will move to projectuiapi in 7.4
> timeframe. It would simplify some other new APIs which were are creating for
> 7.4. Depending on the time I would like to submit a patch which does the change
> and updates SE/EE project types. Should be relatively small change. That would
> result into deprecation of CustomizerProvider2 in java.api.common. In that
> light I suggest that your CustomizerProvider3 extends directly
> CustomizerProvider to avoid depending on soon to be deprecated class.

To move forward I initiated another API review to address this (see Issue #229351). Should it be accepted, the change here would be trivial. I should just note that CustomizerProvider3 should preferably extend CustomizerProvider2 and not CustomizerProvider.


> re MK1 and MK2 - (my two cents) the workflow does not sound very logical: user
> did a change in Project Properties and the change needs to close the Project
> Properties dialog and so you call closeCustomizer() to "cancel" all changes
> done in Project Properties. If it is really rarely used action why not to just
> show in UI "changes will be visible upon reopening project properties dialog"
> and let user do that.

It is not a common workflow but the usecase we need to address is not common either (but it is requested not). We need to provide an option for users to modify SE/FX Project deployment model on the fly. This is possible and there seems to be demand for it; SE Project can be used for developing with limited FX support (by embedding FX components to JFXPanel), but SE Project produces still a Swing based project with a standard main class that just embeds FX into Swing containers and needs to deal with various unpleasant issues like the synchronization between Swing and FX event queues, etc. Pure FX project does not use Swing at all, traditional main class is ignored, the application is launched through javafx.application.Application.start() method, and by default the FX build system creates artifacts supporting adjusted FX-WebStart and FX browser plugin technologies, where the build system allows defining many settings that are not available in SE while ignoring some of the SE ones. Within NetBeans though the FX Project is implemented as an extension of SE Project. So the usecase we are addressing is "switching on" the FX extension on top of SE Project.

This switch is a one-time infrequent operation than should not be presented in any prominent place in the IDE UI. It makes sense to provide it in Project Properties' Deployment panel though because the difference between SE and FX project is primarily in deployment of the application.

The reason for abandoning any changes made so far in the Project Properties dialog in case the switch is invoked is as stated above - the FX extended project takes use of a large set of properties that are not available in SE and at the same time replaces/hides some of the SE specific ones. Adjusting the opened Project Properties dialog directly as a result of this switch in not realistic, (and NB infrastructure is not prepared for that), because several categories/panels need to be added/removed/changed. Therefore we opt for the solution described above. This information is also to be presented to the user and a warning/confirmation dialog will be shown before the switch SE-to-FX would actually have been accomplished, so that users would understand that the switch has the relatively far reaching consequences (and that preserving SE settings in the dialog does not make sense).

Integrated into 'main-golden', will be available in build *201305042300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/b5b8c64ea8ca
User: Petr Somol <psomol@netbeans.org>
Log: Add Deployment panel to SE Project Properties (see also #229161)

Thanks for the detailed explanation.

re MK1/2 I would suggest to rename the method to more explicit cancelCustomizer() rather that the current closeCustomizer() that doesn't express the behaviour entirely.

(In reply to comment #9)
> re MK1/2 I would suggest to rename the method to more explicit
> cancelCustomizer() rather that the current closeCustomizer() that doesn't
> express the behaviour entirely.

renamed to cancelCustomizer() and updated spec versions.
as there was no more comments I have pushed to jetmain today
http://hg.netbeans.org/jet-main/rev/e73bb43fb828

Integrated into 'main-golden', will be available in build *201305172300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e73bb43fb828
User: Petr Somol <psomol@netbeans.org>
Log: #229161 - Add API to enable cancelling project customizer dialog programmatically