Large A complex upgrade project will may have many upgrade tasks (VBPs) and many upgrade features. The ScriptRules feature provides a means for organizing translation script rules into files based on upgrade features and then applying the content of those files to the upgrade tasks conditionally.
Script rules are placed in a ScriptRule.xml file one or more ScriptRule files which defines collections of script commands that may be conditionally merged with the translation script template to create different actual translation scripts. The ScriptRule syntax supports script parameters and conditional commands. This makes it possible, in one template, to describe a variety of common and task-specific upgrade commands.
ScriptRule files are also helpful for API-based upgrades tasks. These tasks use an EXE an custom migration executable implemented using gmslAPI rather than a XML script template. gmBasic. The gmslAPI includes the ScriptRule class to assist with preparing a ScriptRule file content for use by the gmslAPI services.
...
Most of the documentation for using ScriptRules is maintained in the sample ScriptRules file distributed with the product and listed below. To you this file, add it to your user folder, modify it with the rules you need, and reference it from your main script template.
Code Block | ||
---|---|---|
| ||
<!-- ScriptRule FileOverview Syntax The A ScriptRule.xml file defines named iscollections anof XMLscript documentcommands that may contain one ormay morebe ScriptRuleconditionally merged with the template elements.translation script Thesecreating elements and their attributes aredifferent actual describedtranslation belowscripts. This <ScriptRule id="name" Condition="condition" > elementsmakes it possible, with one ScriptRuletemplate, elementsto containautomate nameda scriptvariety commandof collectionscommon and task-specific upgrade options. The idScriptRule attributefiles isare thealso nameneeded offor theAPI-based ScriptRuleupgrade andtasks. is alsoThese used tasks inuse youran translationEXE scriptimplemented tousing activategmAPI therather rule.than a XML script template. The Condition attribute is used toThe controlgmAPI whichframework rulesincludes area ScriptRule mergedclass intoproviding services to to the actualintegrate translationScriptRule script.file content <Command Condition="condition"> elements Command elements are children of a ScriptRule that specify the content that should be merged into the translation script template. The following types of Command elements are currently supported: Option Inserts commands that replace the <ScriptRule> tag in the merged transcript, typically Select, Reference, and Registry commandswith other gmAPI services. ScriptRule File Syntax A ScriptRule file is an XML document that may contain one or more ScriptRule elements. These elements and their attributes are described below. <ScriptRule id="name" Condition="condition" > elements ScriptRule elements contain named script command collections The id attribute is the name of the ScriptRule and is also used in your translation script to activate the rule. The Condition attribute is used to control which rules are merged into Compile to the actual Insertstranslation commandsscript. as children of the Compile block. Typically <Command Condition="condition"> elements Command elements are children of a ScriptRule that specify the content that Select,should Reference,be Fix,merged andinto Refactorthe commands.translation script template. The following types of Command elements are currently supported: Option Analyse Inserts commands asthat children ofreplace the Analyse<ScriptRule> blocktag in the PreAnalyse Inserts commands before the Analyse block, typically refactor commands PostAnalyse Inserts commandsmerged aftertranscript, thetypically AnalyseSelect, blockReference, typicallyand refactorRegistry commands. Author Load InsertsInsert commands as children of the AuthorLoad block, typically Fix commands . Typically Fixcommands. Compile PostAuthor Inserts commands as children afterof the AuthorCompile block,. typicallyTypically top level gmPL commands The Condition attribute is used to control which commandsSelect, areReference, mergedFix, intoand Refactor commands. to the actual translation script. Condition attributesAnalyse A ConditionInserts attributecommands mayas bechildren appliedof tothe anyAnalyse otherblock element. It specifies thePreAnalyse Inserts commands conditionbefore underthe whichAnalyse theblock, elementtypically andrefactor itscommands children will be mergedPostAnalyse with theInserts commands after the Analyse templateblock, scripttypically torefactor createcommands the actual script. SyntaxAuthor Inserts commands as children of the Author block, typically %variable_expression%Fix opcommands 'value_expression' PostAuthor Inserts wherecommands after the Author block, typically top level gmPL variable_expressioncommands all script variablesThe andCondition otherattribute charactersis used to control which commands opare merged into to the actual translation script. Condition attributes A ==Condition trueattribute ifmay %variable_expression% == value_expression be applied to any other element. It specifies the condition under which the element and its children will be merged with the != true iftemplate %variable_expression% != value_expression script to create the actual script. Syntax %variable_expression% =~ true if %variable_expression% matches regex value_expression op 'value_expression' where variable_expression all script variables and other characters op !~ true if %variable_expression% does not match regex value_expression == true if %variable_expression% == value_expression value_expression a constant string or regex pattern != true if %variable_expression% != value_expression Comparisons are case insensitive using trimmed strings. =~ true if %variable_expression% matches regex value_expression Relational operators are not supported, but you can use Condition="var1.var2=='val1.val2'" to simulate locical AND Condition="var=~'val1|val2'"!~ true if %variable_expression% does not match regex value_expression to simulate logical OR For example Condition="%SrcName%=='ScanToolUI'" indicates that the associated value_expression a constant string or regex pattern element will only be merged for upgradeComparisons tasksare havingcase SrcNameinsensitive equalusing trimmed strings. to the string "ScanToolUI". Relational operators are not <ForEach>supported, <Iterator>,but andyou <Each>can elementsuse ForEach elements are children of the ScriptRule. They allow repeating Command elements for each file in the source project folder that meet certain criteria. This element may also be used to copy files from the source project folder to the .NET project folder. The set of files to iterate over is defined by a <Iterator/FileInfo> element according to its attributes: Condition="var1.var2=='val1.val2'" to simulate locical AND Condition="var=~'val1|val2'" to simulate logical OR For example Condition="%SrcName%=='ScanToolUI'" indicates that the associated element will only be merged for upgrade tasks having SrcName equal to the string "ScanToolUI". The FileInfo Criteria attribute is a search pattern (e.g. *.wav) used to <ForEach>, <Iterator>, and <Each> elements get filesForEach fromelements theare sourcechildren folder.of the ScriptRule. They allow repeating TheCommand FileInfoelements Filesfor attributeeach mayfile bein "All"a or "Top". The default is "All". If Files="All", the root of the source folder and all of its sub-folders are searched; if Files="Top", only the root of the source folder is searched. The CopyFiles attribute may be "On" or "Off". The default is "On". If CopyFiles="on", the files found in the source project folder will be copied to the corresponding .NET project folder with directory structure preserved. The folders and files are copied prior to the translation process. Within the <Each> block, the notation %FileInfo.member% may be used to refer to information about the files found in the source folder: %FileInfo.RelativeName%: path relative to the source project root %FileInfo.Name%: file name %FileInfo.FullName%: full path %FileInfo.DirectoryName%: parent folder name Activating a ScriptRule Adding a <ScriptRule> tag to the script requests the merging of the named script collection. <ScriptRule id="name" attributeList /> The id attribute specifies the command collection to add. The attributeList specifies variables that may be referenced elsewhere in the ScriptRule. Variable references are case insensitive. For example the following ScriptRule tag: <ScriptRule id="IncludeResources" Criteria="*.wav" /> requests loading the command collection named IncludeResouces and creates a ScriptRule variable named %Criteria% with value = "*.wav" Specifying the ScriptRule file By default, the ScriptRule XML is located in a file called ScriptRule.xml and is typically kept in the workspace\usr folder. If desired, you may specify an alternate location using a FileName attributespecified folder that meets certain criteria. This element may also be used to copy files from the specified folder to the .NET project folder. The set of files to iterate over is defined by a <Iterator/FileInfo> element according to its attributes: The FileInfo@Criteria attribute is a search pattern (e.g. *.wav) used to get files from the source folder. The FileInfo@Folder attribute specifies the folder to search for files. The default is the source folder associated with the upgrade task. %SrcFolder%, %UserFolder%, and %ProjFolder% script variables may also be used. The FileInfo@Recurse attribute may be "All" or "Top". The default is "All". If Files="All", the root of the source folder and all of its sub-folders are searched; if Files="Top", only the root of the source folder is searched. The FileInfo@CopyFiles attribute may be "On" or "Off". The default is "On". If CopyFiles="on", the files found in the source project folder will be copied to the corresponding .NET project folder with directory structure preserved. The folders and files are copied prior to the translation process. Within the <Each> block, the notation %FileInfo.member% may be used to refer to information about the files found in the source folder: %FileInfo.RelativeName%: path relative to the source project root %FileInfo.Name%: file name %FileInfo.FullName%: full path %FileInfo.DirectoryName%: parent folder name Activating a ScriptRule Adding a <ScriptRule> tag to the script requests the merging of the named script collection. <ScriptRule id="name" attributeList /> The id attribute specifies the command collection to add. The attributeList specifies variables that may be referenced elsewhere in the ScriptRule. Variable references are case insensitive. For example the following ScriptRule tag: <ScriptRule id="IncludeResources" Criteria="*.wav" /> requests loading the command collection named IncludeResouces and creates a ScriptRule variable named %Criteria% with value = "*.wav" Specifying the ScriptRule file By default, the ScriptRule XML is located in a file called ScriptRule.xml and is typically kept in the workspace\usr folder. If desired, you may specify an alternate location using a FileName attribute for example: <ScriptRule id="ADODBUpgrade" FileName="..\usr\ADODB.Rules.xml" /> The above loads the ScriptRule file named ..\usr\ADODB.Rules.xml (relative to the workspace log folder). And then merges in the ScriptRule element having id="ADODBUpgrade": <ScriptRule id="ADODBUpgrade" Condition="%TaskTag%=='upg'" > ... rules to perform ADODBUpgrade for tasks having TaskTag=='upg' ... </ScriptRule> See Also: For more information, see the "Eval" VB6 Upgrade sample here https://portal.greatmigrations.com/display/GMG/Samples --> <ScriptRules> <!-- Here is a sample of the ScriptRule syntax --> <ScriptRule id="BasicRulesStandardUpgrade"> <Option> <!-- directories for configuration files --> <select Target="%UserFolder%" /> <Select Local="%IdfFromCodeFolder%" /> <Select System="%IdfFromIdlFolder%" /> <!-- translation options --> <Select Progress="1" /> <Select DevEnv="%DevEnv%" /> <Select Dialect="%Dialect%" /> <Select BuildFile="local" /> <!-- directories for deployment and external assemblies --> <select VirtualRoot="%VirtualRoot%" /> <Select DeployLocation="%NetProjFolder%" /> <Select Library="%RuntimeFolder%" /> <!-- custom processing commands --> </Option> <Compile Condition="%SrcName%=~'Project1|Project2'" > <!-- pre-edits --> <!-- compile refactors commands--> </Compile> <PreAnalyse> <!-- pre-analyse refactor commands --> </PreAnalyse> <PostAnalyse> <!-- post-analyse refactors commands--> </PostAnalyse> <Author Condition="%SrcName%=~'Project1|Project2'" > <!-- post-edits --> </Author> <PostAuthor> <!-- post-author refactors commands--> </PostAuthor> </ScriptRule> </ScriptRules> |