Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "JWT Modifications"

(Externalize your Strings)
(Externalize your Strings)
Line 35: Line 35:
  
 
=== Externalize your Strings ===
 
=== Externalize your Strings ===
* If your string is related to UI, then it '''must''' be externalized and referenced from a NLS Message Bundle
+
* If your string is a UI message (ie title, content of a dialog...), then it '''must''' be externalized and referenced from a NLS Message Bundle
 +
* If your string is an EMF-generated class (seek for @generated annotation on class comments), then simply put a '''@SuppressWarnings("nls")''' on that class
 
* If your string is a "logic" string (for examples if it the name of a plugin extension point attribute, or "true"/"false" strings) and if it is used several times, then create a constant for that string and use it.
 
* If your string is a "logic" string (for examples if it the name of a plugin extension point attribute, or "true"/"false" strings) and if it is used several times, then create a constant for that string and use it.
 
* It your string is '''never''' intended to be displayed (for example log messages or bundle names...) then, add a //$NON-NLS-''n''$ comment.
 
* It your string is '''never''' intended to be displayed (for example log messages or bundle names...) then, add a //$NON-NLS-''n''$ comment.

Revision as of 06:05, 5 February 2009

This page provides information to JWT contributors on how to add modify and add new features to the JWT Workflow Editor (JWT-WE).

Overview

The JWT Workflow Editor defines several extension points and mechanisms that allow users to customize and extend the abilities and properties of JWT-WE without changing the editor itself. However, there may be cases in which it becomes necessary to alter the Workflow Editor code itself, notably when the new features need to be implemented by committers of the JWT project. This page is intended to describe how JWT committers can deal with recurring tasks when adding features to the Workflow Editor like adding new options to the Eclipse preferences dialog (if you're instead looking for information on how to extend JWT-WE through providing external plugins, please take a look at JWT_Extensions).

Writing (Example) Plugins for JWT-WE

General Standards for Plugins

  • Provider: Eclipse.org
  • Required Execution Environment: Java 1.5
  • CVS: In the we/jwt-we-plugins/PLUGINDIR
  • Versioning: x.y.z.qualifier, same as corresponding Workflow Editor release (see Version Numbering)
  • Legal: Must contain EPL, CQ

Standards for Example Plugins

  • Project Directory: jwt-we-PLUGINTYPE-example (e.g. view, sheet, ...)
  • Project Name: JWT WE PLUGINTYPE Example Plugin
  • Package Structure: org.eclipse.jwt.we.plugins.PLUGINTYPEexample

Standards for Productive Plugins

  • Project Directory: jwt-we-PLUGINTYPE-PLUGINNAME (e.g. viewuml, doc, ...)
  • Project Name: JWT WE PLUGINNAME Plugin
  • Package Structure: org.eclipse.jwt.we.plugins.PLUGINNAME

Documentation of your Source Code

  • For all files you _modified_, you have to add yourself to the list of contributors in the legal header of the file
  • For all files you _created_, you have to add the same header as other source files include. Update the date, the creator and the copyright (that belongs to Bull)
  • Please remove all "development" comments
  • The target runtime environment of plugins must be set to J2SE-1.5

Externalize your Strings

  • If your string is a UI message (ie title, content of a dialog...), then it must be externalized and referenced from a NLS Message Bundle
  • If your string is an EMF-generated class (seek for @generated annotation on class comments), then simply put a @SuppressWarnings("nls") on that class
  • If your string is a "logic" string (for examples if it the name of a plugin extension point attribute, or "true"/"false" strings) and if it is used several times, then create a constant for that string and use it.
  • It your string is never intended to be displayed (for example log messages or bundle names...) then, add a //$NON-NLS-n$ comment.

Integrating new Features into JWT-WE

Adding Preferences

notes:

  • konstanten in preferenceconstants
  • standardwerte in preferenceinitializer
  • zugriffselemente in preferencereader
  • beschriftung in plugin*.properties
  • feldelemente in preferencepages
  • preferences über preferencereader auslesen
  • aktualisierung durch preferencechangelistener

neue seite:

  • category in preferenceconstants
  • category in preferencechangelistener
  • page in pages erstellen
  • seite in plugin.xml hinzufügen
  • category in plugin.properties eintragen

Adding Menu/Toolbar Entry

See also

Back to the top