Tigerstripe Template Design
Revision as of 04:52, 23 July 2008 by Rcraddoc.cisco.com
- The implementation will be delivered in phases:
- 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)
- 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
- 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).