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.
Difference between revisions of "Tigerstripe Template Design"
(New page: __TOC__ == Phases == * The implementation will be delivered in phases: ** Phase I for the Alize Release ** Phase II for the [[Tigerstripe_Bora_Release|Bora R...) |
(→High Level Design Notes) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 7: | Line 7: | ||
===Phase I === | ===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 | * 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) | * Built-in types to be created thru built-in templates (ie. use the same mechanism throughout) | ||
| Line 24: | Line 24: | ||
** a top level Artifact Creation Request | ** a top level Artifact Creation Request | ||
** and a set of "other" Requests (set, etc...) | ** 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: | * 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). | ** 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) | ** 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 | * All templates held in the TemplateFactory should be visible from | ||
| − | ** a right-click on the Pacakge Explorer (new->...) | + | ** The tigerstripe menu (Node & Relationship). We need to consider what the "top level" or default menu button looks like. |
| − | ** as a creation Tool on the Class Diagram Palette. | + | ** 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). | ||
| + | |||
| + | |||
| + | [[Category:Tigerstripe]] | ||
Latest revision as of 04:52, 23 July 2008
Phases
- The implementation will be delivered in phases:
- Phase I for the Alize Release
- Phase II for the Bora Release
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).