## Learn about Templates

In order to create a valid template, there is an order we need to maintain to get all the data from the prototype correctly. To do this, we have a hierarchy file from where we will be getting the document structure. This file is located in the “templates” folder inside the installation folder and is called “hierarchy.xml”.

This hierarchy has a base node called PrototyperInfo. This tag is the root node from all the nodes in the template and is implicit in the document. As the child of this node, there are the main properties of your prototype as well as the main categories.

Logo: the logo specified from prototype
ProjectName: the name of you prototype
CreationDate: the current date the document was generated
NavigationMap: the sitemap from your prototype

There are also 6 main categories that define the main branches of your prototype:

Screens  all the screens from the prototype
Templates  all the templates from the prototype
Scenarios  all the scenarios from the prototype
DataMasters  all the data masters from the prototype
Comments  all the comments from the prototype
Requirements  all the requirements from the prototype

Each one of this category is a holder for all the items of its category. Inserting one of those tags, will trigger a recursive loop, printing all the items it has inside.We’ll start by explaining the categories and what you can find inside them.

Screens / Templates

Screen: a description of a screen, which will be repeated for every screen in the project. Note the repeat modifier in the node which allows the repetition of content.

ScreenName: inserts the screen’s name.

ScreenImage: inserts the screen’s screenshot.

ScreenTemplate: replaces the selected text as the name of the template, which is used by the screen.

ScreenAccessible: substitutes the selected text by an indicator of whether or not, the current screen is accessible from the home screen.

ScreenDescription: substitutes the selected text by the screen description.

ScreenMyWidgets: inserts the screen’s MyWidgets.

ScreenWidgets: inserts the screen’s elements containing interactions.

ScreenComments: inserts the screen’s comments.

ScreenRequirements: inserts the screen’s requirements.

ScreenDynamicPanels: inserts the screen’s other states.

ScreenMenus: inserts the screen’s menus.

ScreenTrees: inserts the screen’s trees.

ScreenMyWidgets

hasScreenMyWidgets: evaluates if there are MyWidgets in the screen.

ScreenMyWidget: inserts the MyWidgets elements in the screen. Note the repeat modifier in this node.

ScreenMyWidgetName | ScreenMyWidgetRelatedTo | ScreenMyWidgetMarkerID: inserts the MyWidget name, image and number related to the screen markers (if present).

ScreenWidgets

hasScreenWidgets: evaluates if there are elements in the screen with interactions.

ScreenWidget: inserts the elements that have interactions in the screen. Note the repeat modifier in this node.

ScreenWidgetScreenshot: evaluates if there are elements in the screen with

ScreenWidgetMarkerID: returns the number this element has in the screen when markers are active.

ScreenWidgetEvent: repeats all the events from this widget.

ScreenWidgetEventType: inserts the name of the event (onClick, onMouseOver…)

ScreenWidgetInteraction: repeats all the interactions from a given event.

ScreenWidgetInteractionName: inserts the name of the interaction.

ScreenWidgetConditionBlock: inserts all the blocks an interaction has.

ScreenWidgetConditionClause: returns an “if”, “else if” or “else” indicating the execution order in the interaction, as seen in the interactions’ panel in Prototyper.

ScreenWidgetConditionDescription: gives a description of the condition of this block.

ScreenWidgetAction: repeats all the action a block has.

ScreenWidgetDescription: gives a description of this action.

ScreenWidgetTarget: inserts the image of the target of this action.

ScreenComments

hasScreenComments: returns if there are comments or not given a screen.

ScreenComment: the comments node, which will be repeated for every screen in the project. Note the repeat modifier in the node which allows the repetition of content.

ScreenCommentAuthor | ScreenCommentDate | ScreenCommentContent: returns the author, date and comment content for each comment.

ScreenCommentRelatedTo: inserts an image of the comment holder.

ScreenCommentMarkerID: returns the number this element has in the screen when markers are active.

ScreenRequirements

hasScreenRequirements: returns if there are requirements or not given a screen.

ScreenRequirement: a general description of a requirement, which will be repeated itself for every requirement in the project. Note the repeat modifier in the node which allows the repetition of content.

ScreenRequirementCode: inserts the requirement’s code.

ScreenRequirementCreationDate: adds the creation date.

ScreenRequirementAuthor: sets the requirement’s author.

ScreenRequirementCurrentVersion: states the currently active version number.

ScreenRequirementRelatedTo: references the component to which the requirement is related to, such as screens, templates, scenarios or components.

ScreenRequirementMarkerID: returns the number this element has in the screen when markers are active.

ActiveVersion | Author | Date | Type | Name | Source | Description | Comments | FitCriteria | Tests | Justification: requirement descriptors of the current version.

ScreenRequirementVersion: a general description, which repeats itself for every requirement version.

ScreenDynamicPanels

hasScreenDynamicPanels: returns if there are any dynamic panels given a screen.

ScreenDynamicPanel: a general description of a screen state, which will be repeated itself for everyone in the screen. Note the repeat modifier in the node which allows the repetition of content.

ScreenDynamicPanelImage: inserts the image of a screen state.

ScreenDynamicPanelName: returns the name of the state.

For the other options, look at the Screen categories, as they have the same content as explained previously. For having the correct tag names, look at the xml hierarchy file.

ScreenMenus

hasScreenMenus: returns if there are any menus in the screen.

ScreenMenu: a general description of a menu, which will be repeated itself for everyone in the screen. Note the repeat modifier in the node which allows the repetition of content.

ScreenMenuImage: inserts the image of a menu.

ScreenMenuName: returns the name of the menu.

For the other options, look at the Screen categories, as they have the same content as explained previously. For having the correct tag names, look at the xml hierarchy file.

ScreenTrees

hasScreenTrees: returns if there are any menus in the screen.

ScreenTree: a general description of a menu, which will be repeated itself for everyone in the screen. Note the repeat modifier in the node which allows the repetition of content.

ScreenTreeImage: inserts the image of a menu.

ScreenTreeName: returns the name of the menu.

All this tags only work for screens, but the structure is practically the same for templates. Look the xml hierarchy to learn the appropriate names for the templates.

Scenarios

Scenario: a description of a scenario, which will be repeated itself for every scenario in the project. Note the repeat modifier in the node which allows the repetition of content.

ScenarioName: inserts the scenario’s name.

ScenarioImage: inserts a screenshot of the scenario.

ScenarioDescription: inserts the scenario description.

ScenarioComments: lists the comments related to the scenario. For more information about the tags, go to the Comments section and refer to the xml hierarchy for the specific names.

ScenarioRequirements: lists the requirements related to the scenario. For more information about the tags, go to the Requirements section and refer to the xml hierarchy for the specific names.

DataMasters

Data Master: a description of a data master, which will be repeated itself for every data master in the project. Note the repeat modifier in the node which allows the repetition of content.

DataMasterName: inserts the data master’s name.

DataMasterAttribute: text, which repeats itself for every data master field.

DataMasterAttributeName | DataMasterAttributeType | DataMasterAttributeValue: name, type and values (if any) of each attribute.

Comments

Comment: a general description of a comment, which repeats itself for each comment in the project. Note the repeat modifier in the node which allows the repetition of content.

CommentAuthor | CommentDate | CommentContent: author, creation date and content of a comment.

CommentRelatedTo: image of the element which has the comment.

Requirements

Requirement: a general description of a requirement, which will be repeated itself for every requirement in the project. Note the repeat modifier in the node which allows the repetition of content.

RequirementCode: inserts the requirement’s code.

RequirementCreationDate: adds the creation date.

RequirementAuthor: sets the requirement’s author.

RequirementCurrentVersion: states the currently active version number.

RequirementRelatedTo: references the component to which the requirement is related to, such as screens, templates, scenarios or components.

ActiveVersion | Author | Date | Type | Name | Source | Description | Comments | FitCriteria | Tests | Justification: requirement descriptors of the current version.

RequirementVersion: a general description, which repeats itself for every requirement version.

Other

You can see some tags in the root category, having a “condition” modifier. Those tags are very useful to include or not include some information. You can make you template as complete as you want but, using the tags, you can prune content from the result if the condition evaluates to false.

You will find these tags as children of the main node, but there are some more inside the hierarchy, to customize the resulting template. For as nearly as every category, there are conditional tags to include or not the information.
An example of this would be if our template has the data masters information in order to display it, but we have no data masters in our prototype. In that case, we can do two things:

- Edit the template and remove all the information about data masters.
- Use a condition so, if there are no data masters from the prototype, this condition will evaluate to false and therefore, will not print any information it has inside.