Example screen definition—XML with commentary

<definition hasDetail="true" hasSearch="true" hasTree="true" screen="search" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../definition-schema.xsd" customised="true">
<!-- <definition> must have an attribute namely 'customised' set and set to true -->
 <meta>
 <name>mye950</name>
 <!-- Name of the custom application. It should have exactly 6 characters. It must have it's third character as E -->
 CCLAS 6 Online HelpMy.Account.Hierarchy</title>
 <isMsk>false</isMsk>
 <!-- This represents the initial state of the screen. Most standard applications use 'search', however it's possible to have values of 'create' and 'read'. 
 However, I would caution to only use 'read' or 'create' by referring to an existing application with these values. Creating a screen from scratch using 'read' or 'create'
 requires supporting services. e.g. 'read' would require you have a service to actually read something initially -->
 <initial>search</initial>
 <rootApplication>mse950</rootApplication>
 <!-- Ensure you're clear on the DTO you're using for this screen. Find the BOC documentation to understand the DTO / Search param names -->
 <coreDtoName>com.mincom.ellipse.types.m3960.instances.ReportNodeSearchParam</coreDtoName>
 <coreAppName>mse950</coreAppName> 
 <!-- Core application based on which the custom application was created. 
 It is not required when customisationType is 'new' ie. when you are creating a completely new application. 
 -->
 <customisationType>copy</customisationType> 
 <!-- Type of customisation. It should be one of below. 
replace: Specified when custom application replaces a core application. So, obviously <name> should be same as <coreAppName>.
 copy: Specified when custom application extends a core application. So, <name> should be different from <coreAppName> and <name> must not start with MS and must have E as its third character.
new: Specified when custom application doesn't replace or extend a core application. But <name> still must not start with MS and must have E as its third character.
 -->
 <screen>SEARCH</screen>
 <!-- Screen name : Should be one of search, detail or tree -->
 <customName>950</customName>
 <!-- Alias for the custom application. 
 It should not exceed 20 characters.There should not be any application with the specified customName
 -->
<!-- Screen Definition Tags. Refer to the Screen Definition Tags pdf downloadable from the Online Technical Documentation -->
 </meta>
 <layout>
 <!-- The form basically encompasses all visual elements on the screen -->
 <form> 
 <FieldGroup id="search">
 <FieldGroup id="groupSearch">
 <DropDown length="4" _case="csUpper" table="MSF000DISTRICT" type="btChar" id="districtCode" label="District" mandatory="true" primaryKey="true" contextLookup="loggedOnDistrictCode" />
 <FieldGroup id="option">
 <Enum length="1" id="option1" attribute="option" label="MyOption">
 <Literal data="" />
 <Literal data="S" value="Subordinates.for.a.Parent" />
 <Literal data="P" value="Parents.for.a.Subordinate" />
 </Enum>
 </FieldGroup>
 <FieldGroup id="summaryNode">
 <ServiceDropDown length="24" _case="csUpper" dataField="reportNode" descField="description" type="btChar" serviceName="com.mincom.ellipse.service.m3960.reportnode.ReportNodeService" serviceOperation="search" id="reportNode" label="My.Summary.Node">
 <requestPairings>
 <FieldPairing insides="{['districtCode']}" outside="districtCode" />
 <FieldPairing insides="{['reportNode']}" outside="generalLedgerCode" />
 <FieldPairing outside="reportNodeSearchMethodRestrictable" literal="W" />
 <FieldPairing insides="{['reportNode']}" outside="reportNode" />
 </requestPairings>
 <LookupAction targetApplication="mse950" id="lookupmse950">
 <requestPairings />
 <returnPairings>
 <FieldPairing insides="{['reportNode']}" outside="reportNode" />
 </returnPairings>
 </LookupAction>
 </ServiceDropDown>
 <ServiceDropDown length="24" _case="csUpper" dataField="accountCode" descField="accountCodeDesc" type="btChar" serviceName="com.mincom.ellipse.service.m3960.accountcodeinput.AccountCodeInputService" serviceOperation="search" iterativeSearch="true" id="accountCode" label="My.Account.Code">
 <requestPairings>
 <FieldPairing insides="{['accountCode']}" outside="enteredCode" />
 <FieldPairing insides="{['districtCode']}" outside="districtCode" />
 </requestPairings>
 <LookupAction targetApplication="mse966" id="lookupmse966">
 <requestPairings />
 <returnPairings>
 <FieldPairing insides="{['accountCode']}" outside="accountCode" />
 </returnPairings>
 </LookupAction>
 </ServiceDropDown>
 </FieldGroup>
 <FieldGroup id="status">
 <Enum length="1" id="status1" attribute="status" label="My.Status">
 <Literal data="A" value="Active" />
 <Literal data="D" value="Draft" />
 <Literal data="" />
 </Enum>
 </FieldGroup>
 </FieldGroup>
 </FieldGroup>
 <FieldGroup id="results">
 <FieldGroup label="My.Search.Results" id="groupResultsParent">
 <SearchGrid id="groupResults" label="My.Search.Results" service="com.mincom.ellipse.service.m3960.reportnode.ReportNodeService" operation="searchAccountHierarchy" dtoType="com.mincom.ellipse.types.m3960.instances.ReportNodeSearchDTO" searchDtoType="com.mincom.ellipse.types.m3960.instances.ReportNodeSearchParam" targetApplications="{[['mse950',{'nodeType':'2'}],['mse9501',{'nodeType':'0'}],['mse9502',{'nodeType':'1'}]]}">
 <columns>
 <DropDown length="4" _case="csUpper" table="MSF000DISTRICT" type="btChar" id="groupResultsDistrictCode" hidden="true" attribute="districtCode" label="District" mandatory="true" primaryKey="true" />
 <Input length="24" _case="csUpper" id="groupResultsReportNode" attribute="reportNode" label="Summary.Node" mandatory="true">
 <LookupAction targetApplication="mse950" id="lookupmse9501">
 <requestPairings />
 <returnPairings>
 <FieldPairing insides="{['reportNode']}" outside="reportNode" />
 </returnPairings>
 </LookupAction>
 </Input>
 <Input length="24" _case="csUpper" id="groupResultsAccountCode" attribute="accountCode" label="Account.Code">
 <LookupAction targetApplication="mse966" id="lookupmse9661">
 <requestPairings />
 <returnPairings>
 <FieldPairing insides="{['accountCode']}" outside="accountCode" />
 </returnPairings>
 </LookupAction>
 </Input>
 <Input length="20" id="groupResultsName" hidden="true" attribute="name" label="Name" />
 <Input length="40" id="groupResultsDescription" attribute="description" label="Description" />
 <Enum length="1" id="groupResultsStatus" attribute="status" label="Status">
 <Literal data="A" value="Active" />
 <Literal data="D" value="Draft" />
 <Literal data="" />
 </Enum>
 <Input length="24" _case="csUpper" id="groupResultsTopReportNode" attribute="topReportNode" label="Top.Summary.Node">
 <LookupAction targetApplication="mse950" id="lookupmse9502">
 <requestPairings />
 <returnPairings>
 <FieldPairing insides="{['topReportNode']}" outside="reportNode" />
 </returnPairings>
 </LookupAction>
 </Input>
 <TextArea length="80" id="groupResultsTopReportNodeDescription" attribute="topReportNodeDescription" label="Top.Summary.Node.Description" />
 </columns>
 <flowActions />
 </SearchGrid>
 </FieldGroup>
 </FieldGroup>
 </form>
 <!-- In between the dialogs tag is where you'd define all the dialogs that can be called in this screen.
 How to actually do this can be found in plenty of examples of application screens with dialogs. e.g. MSE140 -->
 <dialogs />
 <!-- In between the flows tag is where you'd define all the flows that would render at the top of the screen. -->
 <flows />
 </layout>
 <!-- Actions define the key service methods that is invoked when the user performs the various actions supported by the screen. 
 Typically these actions drive the Submit and Search buttons -->
 <actions>
 <SearchCreateAction id="create" serviceName="com.mincom.ellipse.service.m3960.reportnode.ReportNodeService" serviceOperation="create" />
 <SearchReadAction id="read" serviceName="com.mincom.ellipse.service.m3960.reportnode.ReportNodeService" serviceOperation="read" />
 </actions>
 <!-- Within the behaviour tag is where you define all your Client Side Behaviour (CSB)
 This allows you to control behaviours such as 'show','hide','enable','disable' 
 on most of the elements of the screen based on the value of a Control field. 
 Note that generally MOST RETRICTIVE behaviour wins, 
 this means if you have a conflicting behaviour that tries to show AND hide the same field
 the hide behaviour wins.
 -->
 <behaviour>
 <FieldRestriction components="{[[reportNode],[accountCode]]}" />
 <FieldToggle action="Enable" reverse="true" clearFields="true" control="{option1}">
 <ValueFieldLink values="{['P']}" components="{[accountCode]}" />
 </FieldToggle>
 </behaviour>
 <virtual />
</definition>