Bug 358591

Description Stephan Eberle 2011-09-22 09:42:20 EDT

= Problem description =
Currently, the only way to hook in and use custom implementations of AbstractResultObjectHandler and ResultMessageHandler is to subclass M2MConfigurationWizard or M2TConfigurationWizard and override the respective factory methods:

	M2MConfigurationWizard wizard = new M2MConfigurationWizard(getSelectedModelObject(), getMetaModels()) {
		@Override
		protected IJobChangeListener createResultObjectHandler(XtendJob xtendJob) {
			return new MyResultObjectHandler(xtendJob);
		}
		@Override
		protected IJobChangeListener createResultMessageHandler(M2MJob m2mJob) {
			return new ResultMessageHandler(m2mJob);
		}
	};
	...	
	WizardDialog wizardDialog = new WizardDialog(ExtendedPlatformUI.getDisplay().getActiveShell(), wizard);
	wizardDialog.open();

This is not very straight forward and lets the code look a bit messy for almost nothing. It would be much more preferable if clients could hook in there custom handlers this way:

	M2MConfigurationWizard wizard = new M2MConfigurationWizard(getSelectedModelObject(), getMetaModels()); {
	wizard.setResultObjectHandler(new MyResultObjectHandler());
	wizard.setResultMessageHandler(new MyResultMessageHandler());
	...	
	WizardDialog wizardDialog = new WizardDialog(ExtendedPlatformUI.getDisplay().getActiveShell(), wizard);
	wizardDialog.open();

Aside from that, the current implementation has the disadvantage that there are 2 separate factory methods for ResultObjectHandler in BasicM2MAction and M2MConfigurationWizard. With the approach outlined above it would be sufficient to have just one central factory method in BasicM2MAction, and then use the same resulting ResultObjectHandler instance in BasicM2MAction '''and''' M2MConfigurationWizard. The ResultMessageHandler is currently not supported at all by BasisM2TAction and BasicM2MAction even though it would make totally sense to have it there in the same way as the ResultObjectHander is supported in BasicM2MAction.

= Proposed resolution =
* Implement above mentioned improvements for hooking custom ResultObjectHandlers and ResultMessageHandlers into M2TConfigurationWizard and M2MConfigurationWizard and support both in BasicM2TAction and BasicM2MAction as well
* Revise implementation of AbstractResultObjectHandler and ResultMessageHandler so as to 
** remove the need of passing the enclosing M2x job instance to the constructor of the handler
** move the logic for retrieving XpandJob, XtendJob and CheckJob from the handled M2x job to a common base class named AbstractM2xResultHandler
* Last but not least: rename ResultMessageConstants to IResultMessageConstants so as to conform to Sphinx naming conventions