Difference between revisions of "E4/EAS/Status Reporting"

Revision as of 16:30, 29 October 2009

When operations are initiated, whether by the system or by the end user, it is helpful to be able to provide the user with updates about the status of these operations. This ties in with the progress service in that status reporting is concerned with a customizable way of rendering status information to the user whereas the progress service is concerned with how the work is scheduled and whether status information should be rendered at all or not.

Eclipse 3.x API

The StatusLineManager and the 'Progress' view allows status and progress reporting to be done on it with some limited customization capabilities.

Critique

• The client code (the code reporting a problem) currently has to know too much about how it is reported
  • Need to set the StatusManager styles when calling the status handler
  • When creating a job, need to know the special IProgressConstants job properties to control how status is reported while a job is running.
• The progress manager doesn't play well with wizards and dialogs
  • If you a run a job in a modal dialog, there is no jobs progress dialog
  • If you want to show progress in multiple places, you have to wrap the monitor.

e4 (Java)

Clients should be able to write something like:

@Inject Provider<StatusHandler> statusHandler;
@Inject Provider<StatusReportingService> statusReportingService;
 
public void foo() {
  try {
    // some operation
  } catch (SomeException ex) {
     // I thought this might happen, I think it's an error
     statusHandler.get().handle(ex, IStatus.ERROR, "Error Message", statusReportingService.get());
  } catch (AnotherException ex) {
     // I know nothing about the details, probably an error?
     statusHandler.get().handle(ex, statusReportingService.get());
  }
}

See full example in Status Reporting Service

StatusReportingService

• The StatusReportingService decides how the error is shown
  • local UI context (message area in a wizard or status dialog)
  • centralized UI context (progress view, error dialog)
  • alternate/additional facilities (logging, send to help desk)
• A smart service may be able to offer assistance to the user (quick fixes, take user back to start over, go to the help, open a problem report)
• How are multiple reporting services handled, is only a single one injected?
  • Chains (ordered lists of reporters)
  • Wrapped (a la ProgressMonitorWrapper)
  • Service rankings determine a single winner
    • How to handle a tie?