Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Tigerstripe Template Design


Phase I

  • Template-based wizards with only 1 single page (no look-ahead into the series of actions for the template)
  • No UI editor for templates. We will rely on an XML file that will be registered through an Extension Point, which will fix the use of templates in the UI
  • Built-in types to be created thru built-in templates (ie. use the same mechanism throughout)

Phase II

  • UI for Template creation (i.e. not editing XML file)
  • Ability for users to register/define their own templates unless the Ext. pt (above) is used

High Level Design Notes

  • A TemplateFactory to be driven by the content of an XML file, either stored in the Tigerstripe install of the user or registered through an Ext. pt.
  • "ArtifactTemplates" will apply to an "Artifact" as the top level element (i.e. no "attribute template" by itself, only artifact templates that may contain attributes to be created)
    • "PatternTemplates" may be considered in the future as a composition of ArtifactTemplates
  • ArtifactTemplates have a "plop" method that will lead to a set of "ArtifactRequests" to be passed down to the Artifact Manager.
    • In the case when the Template is used from a Class diagram, the plop(..) method call would only lead to creating the artifact in the model, but wouldn't include it on the diagram. So it should be followed by a "DnD" operation of the newly created artifact on the diagram.
  • Artifact Templates are made of
    • a top level Artifact Creation Request
    • and a set of "other" Requests (set, etc...)
    • Template should allow to create Annotations instances as part of them
  • There are 2 types of Artifact templates:
    • Node Templates (required a name and a package name). (AssociationClasses should be considered a Relationship template as the association ends are required to create it).
    • Relationship Templates (requires all that Node templates require + 2 end types)
  • Custom Auditors will be used to determine the "validity" of the created items, rather than trying to enforce additional controls in the creation phase

UI Aspects

  • Through the Extension Point, it should be possible to disable the "built-in" (standard) templates.
  • All templates held in the TemplateFactory should be visible from
    • The tigerstripe menu (Node & Relationship). We need to consider what the "top level" or default menu button looks like.
    • a right-click on the Pacakge Explorer (new->...) (Node & Relationship)
    • as a creation Tool on the Class Diagram Palette (Node)
    • after a drag operation between valid node types (Relationship)
  • All templates will need to identify an icon and label for the UI usage.
  • All wizards should be replaced by a single generic wizard that would be driven by the content of a template
    • If information is required to be captured, then the wizard will be used. (When accessed via a Diagram, Wizard should be minimal)
    • only the necessary info for the initial creation request should be presented by the wizard
    • default names should be provided in the Wizard (as in the class diagram).

Copyright © Eclipse Foundation, Inc. All Rights Reserved.