Skip to end of banner
Go to start of banner

InputDefinition Refactoring

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

As a part of the

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
ticket, this page will provide the solution to properly refactor the InputDefinition class and all involved components.

Changes in InputDefinition class

  1. Remove the additional options map. The additional properties needed for some sub-views will be tackled by sub-classing the InputDefinition.
  2. Leave the IdDefinition as it is.
  3. Following part of the input definition that is related to the Editor look should be in separated class (for example EditorPropertiesDefinition):
/**
 * The name of the view part.
 */
private String partName;

/**
 * The tooltip is shown when hovering over the view part tab.
 */
private String partTooltip;

/**
 * The imageDescriptor descriptor of the view.
 */
private ImageDescriptor imageDescriptor;

/**
 * String used by the {@link Form} currently to display the text on it.
 */
private String headerText;

/**
 * String used by the {@link Form} currently to display the message on it.
 */
private String headerDescription;

Introducing generics

The place where we would get a lot of from generics would be the InputControllers. The method:

setInputDefinition(InputDefinition)

would the be related to the generic parameter of the controller, passing always the correct type of the input definition.

Since each sub-view has a controller, it would be nice also to include the generics in sub-view. This way we would insure that the sub-view and the controller have the same InputDefinition parameter. This brings the problem that then also the AbstractRootEditor has to be generic, as the EditorInput class that is the one that eventually hold the InputDefinition object.

This means that the complete model is changed. And plus somewhere we need to "cheat" the generics, because the AbstractRootEditor is using IEditorInput eclipse class to get the input, and the sub-view factory to get the sub views. Thus, two places:

(1)
	/**
	 * Returns the input definition for this view.
	 *
	 * @return The input definition.
	 */
	public E getInputDefinition() {
		E inputDefinition = (E) getEditorInput().getAdapter(InputDefinition.class);
		Assert.isNotNull(inputDefinition);
		return inputDefinition;
	}
...
(2)
        SubView<E> subView;

	this.subView = SubViewFactory.createSubView(getInputDefinition().getId());

The first we can solve with reading the generic parameter E before calling to the editor input (Patrice knows how i think), and calling with the correct adapter class. Second can not be solved (smile)

  • No labels