TeamConnect Custom Tool pageDetail Reference Guide

How it works

Custom Tool XML Page (UI)  ──── pageDetail ────>  Java Backing Class (Logic)
     ${pageDetail.myList}       reads from        getMyList()
     PD__MyField__STR           writes to         setMyField(String)
     invokePageDetailAction     calls method      myMethod()

The JSP host page (toolCustom.jsp) renders the custom tool via the <teamconnect:customTool /> tag (class: com.mitratech.teamconnect.webui.taglib.CustomToolTag), which transforms your XML using the pageDetail object as the data context.

Namespace: v1.0 (Custom Tools)

All OOTB Custom Tools use the v1.0 namespace. Within v1.0, there are two syntax styles:

Older style (uses condition= and CL-prefixed components):

<tc:transform version="1.0" xmlns:tc="http://www.w3.org/1999/XSL/Transform">
    <tc:if condition="pageDetail.isEnabled">
        <tc:CLLabel label="Hello" name="myLabel" />
        <tc:CLTextField id="myField" name="PD__MyField__STR" size="50"/>
        <tc:CLCheckBox name="PD__MyFlag__BOOL" id="myFlag" />
        <tc:CLDropDownList name="PD__MySelect__OBJ" list="pageDetail.getMyList" />
    </tc:if>
</tc:transform>

Newer style (uses test= with EL syntax — still v1.0 namespace):

<?xml version="1.0" encoding="UTF-8"?>
<tc:transform version="1.0" xmlns:tc="http://www.w3.org/1999/XSL/Transform">
    <tc:if test="${pageDetail.isEnabled()}">
        <tc:label key="my.label.key" name="myLabel" colon="true"/>
        <tc:out value="${pageDetail.myValue}" />
        <tc:select name="PD__MySelect__OBJ" list="${pageDetail.getMyList()}" />
    </tc:if>
</tc:transform>

Namespace: v4.0 (Screen Designer Screens)

The v4.0 namespace is primarily used by Screen Designer screens (.scr.xml), not Custom Tools. These screens use tc:useClass to declare named Java class instances instead of pageDetail:

<?xml version="1.0" encoding="UTF-8"?>
<tc:transform xmlns:tc="http://www.mitratech.com/schemas/2008/custom" version="4.0">
    <tc:useClass name="MyCustomBlock" id="cjb"/>
    <tc:blockTemplate blockTitleKey="my.block.title" showEdit="false">
        <tc:if test="${cjb.enabled}">
            <tc:text name="UM_myField" value="${cjb.myValue}" forceNotEditable="true" />
            <tc:out value="${cjb.status}" />
        </tc:if>
    </tc:blockTemplate>
</tc:transform>

It IS possible to use the v4.0 namespace for Custom Tools (where pageDetail still works), but this is not the typical OOTB pattern.

Syntax comparison

Simple property access

Accesses the getter method on the Java backing class.

<!-- Newer style: calls getJobStatus() -->
<tc:out value="${pageDetail.jobStatus}" />

<!-- Older style: calls getExceedFeesChargeRuleName() -->
<tc:component componentType="WOString" value="pageDetail.exceedFeesChargeRuleName" />

Boolean conditions

<!-- Newer style: calls isRunning() -->
<tc:if test="${pageDetail.isRunning()}">
    Running...
</tc:if>

<!-- Newer style negation: calls isRunning(), shows content when false -->
<tc:if test="${pageDetail.isRunning()}" negate="true">
    Not running.
</tc:if>

<!-- Older style: calls getIsAFAEnabled() or isAFAEnabled() -->
<tc:if condition="pageDetail.isAFAEnabled">
    AFA is enabled.
</tc:if>

<!-- Older style negation -->
<tc:if condition="pageDetail.isAFAEnabled" negate="1">
    AFA is not enabled.
</tc:if>

Compound conditions (EL syntax only)

Use &amp;&amp; for AND (XML-escaped &&). Requires test= attribute (not condition=):

<tc:if test="${pageDetail.hasCategoryRights &amp;&amp; pageDetail.hasViewRights}">
    ...
</tc:if>

Iterating lists

<!-- Newer style (EL) -->
<tc:forEach items="${pageDetail.stringList}" var="pageDetail.thisString">
    <tc:out value="${pageDetail.thisString}" />
</tc:forEach>

<!-- With nested object properties -->
<tc:forEach items="${pageDetail.columnInfoList}" var="pageDetail.columnInfo">
    <tc:out value="${pageDetail.columnInfo.labelI18nKey}" />
    <tc:out value="${pageDetail.columnInfo.fieldName}" />
</tc:forEach

How tc:forEach works:

1. items — calls the getter (e.g., getStringList()) to get the collection
2. var — on each iteration, calls the setter (e.g., setThisString(item)) on the pageDetail
3. Inside the loop, ${pageDetail.thisString} calls getThisString() to read the current item

Displaying lists in dropdowns

<!-- Newer style -->
<tc:select name="PD__CustomObject__OBJ"
    list="${pageDetail.getCustomObjects()}"
    value="${pageDetail.selectedObjd}"
    allowNullValue="false" />

<!-- Older style -->
<tc:CLDropDownList name="PD__AdjustReason__OBJ"
    list="pageDetail.getAdjustmentReasonList"
    displayStringPath="name"
    allowNullValue="true"
    isAlwaysEditable="true" />

Type suffixes

Examples

<!-- Text field: calls setMyField(String) on pageDetail -->
<tc:CLTextField id="myField" name="PD__MyField__STR" size="50"/>

<!-- Checkbox: calls setIsActive(boolean) on pageDetail -->
<tc:CLCheckBox name="PD__IsRuleActive_FeeChargesExceedFixedFee__BOOL" id="myCheck" />

<!-- Dropdown: calls setAdjustReason(Object) on pageDetail -->
<tc:CLDropDownList name="PD__AdjustReason_FeesExceedsCappedFee__OBJ"
    list="pageDetail.getCappedFeeAdjReasonList"
    displayStringPath="name"
    allowNullValue="true" />

Alternative name patterns

Besides the PD__xxx__TYPE convention, two other patterns are used in OOTB tools:

blockValues['xxx'] — used for key-value settings (seen in TCLTimeEntrySYS):

<tc:select name="blockValues['ShowSelected']"
list="${pageDetail.showList}" />

pageDetail.xxx — used with tc:date to bind directly to a pageDetail property:

<tc:date id="timePeriodDate" name="pageDetail.timePeriodDate" />

PD__BlockValue_xxx__TYPE — a sub-pattern of the PD__ convention for settings stored as block values:

<tc:CLCheckBox name="PD__BlockValue_AFAFixedFeeMatterBasedEnabled__BOOL" />
<tc:CLDropDownList name="PD__BlockValue_AFACappedFeeEnabledAFT__OBJ" />

Using invokePageDetailAction

Executes a method on the Java backing class from a button click:

<input class="mainSearchBtn" id="BUTTON_refresh" name="refresh"
    onclick="invokePageDetailAction(this, 'BUTTON_refresh', 'refresh(*STR)', 'PD__CustomObject__OBJ');"
    type="button" value="${pageDetail.getRefreshKey()}" />

Syntax:

invokePageDetailAction(eventSource, anchorId, 'methodName(*TYPE, *TYPE)', 'fieldName1', 'fieldName2');

• eventSource — usually this
• anchorId — element ID to focus after reload (e.g., 'BUTTON_refresh')
• methodName(...) — the method to call on pageDetail, with parameter type markers
  • *STR — reads value from the named form field as String
  • *OBJ — reads value as Object
  • *BOOL — reads value as boolean
• Remaining args — form field names whose values are passed as method parameters

Using invokeToolAction

Simpler syntax (the JS framework labels this as a "4.x tool action", but it is available globally):

// No parameters
invokeToolAction('myAction')

// With parameters
invokeToolAction('myActionWithArgs', arg1, arg2)

Using top.submitCommand (older style)

Direct command submission used in older-style tools:

<!-- Simple submit -->
<input type="button" value="Save" onclick="top.submitCommand('_self','','PD', 'submit()')" />

<!-- Submit with specific action -->
<input type="button" value="Save AFA Settings"
    onclick="top.submitCommand('_self','','PD', 'updateAFASettings()')" />

<!-- Checkbox onChange triggers submit -->
<tc:CLCheckBox name="PD__MyFlag__BOOL" id="myFlag"
    onClick="top.submitCommand('_self',this.name,'PD', 'submit()')" />

Display tags

Input tags

Navigation tags

Control flow tags

Screen Designer tags (v4.0 namespace)

Batch display tags

Batch display example

<tc:batchDisplay actionNames="${pageDetail.actionNames}"
    batchDisplayObject="pageDetail.batchDisplayObject"
    hideUpdateFunction="true" hideRemoveFunction="true" hideAddFunction="true">
    <tc:batchDisplayTextColumn name="displayString"
        labelI18nKey="my.column.header" required="false" width="50%" />
    <tc:batchDisplayTextColumn name="currentPhaseType.name"
        labelI18nKey="phase.itemName" required="false" width="10%" />
</tc:batchDisplay>

Minimal example

public class MyToolPageDetail extends TCCustomToolPageDetail {

    private String myField;
    private boolean myFlag;
    private List<String> myList;
    private String currentItem;

    // Getter for: ${pageDetail.myField}
    public String getMyField() { return myField; }

    // Setter for: PD__MyField__STR
    public void setMyField(String value) { this.myField = value; }

    // Getter for: ${pageDetail.myFlag}
    public boolean isMyFlag() { return myFlag; }

    // Setter for: PD__MyFlag__BOOL
    public void setMyFlag(boolean value) { this.myFlag = value; }

    // Getter for: ${pageDetail.myList}  (used by tc:forEach items=)
    public List<String> getMyList() { return myList; }

    // Setter for: tc:forEach var="pageDetail.currentItem"
    public void setCurrentItem(String item) { this.currentItem = item; }

    // Getter for: ${pageDetail.currentItem}  (used inside tc:forEach)
    public String getCurrentItem() { return currentItem; }

    // Action method for: invokePageDetailAction(this, '', 'refresh(*STR)', 'PD__MyField__STR')
    public void refresh(String selectedValue) {
        // business logic
    }

    // Action method for: invokeToolAction('doSomething')
    public void doSomething() {
        // business logic
    }
}

AlternativeFeeArrangementSetting (older style)

A settings tool that toggles AFA rule types on/off with configuration options.

Pattern: Uses condition= syntax, CL-prefixed components, and top.submitCommand for actions.

<tc:if condition="pageDetail.isAFACappedFeeEnabled">
    <tc:CLCheckBox name="PD__IsRuleActive_FeesExceedsCappedFee__BOOL" id="myCheck"
        onClick="top.submitCommand('_self',this.name,'PD', 'submit()')" />
    <tc:CLDropDownList name="PD__AdjustReason_FeesExceedsCappedFee__OBJ"
        list="pageDetail.getCappedFeeAdjReasonList"
        displayStringPath="name" allowNullValue="true" isAlwaysEditable="true" />
</tc:if>

AccountConversionTool (newer style)

A batch processing tool that runs async jobs with status tracking.

Pattern: Uses test= with EL syntax (still v1.0 namespace), tc:forEach for failure lists, tc:batchDisplay for data grids, invokePageDetailAction for button actions.

<tc:if test="${pageDetail.isRunning()}">
    <tc:out value="${pageDetail.jobStatus}" />
    <tc:out value="${pageDetail.mattersProcessed}" />
</tc:if>
<tc:if test="${pageDetail.hasFailures()}">
    <tc:forEach items="${pageDetail.failureList}" var="pageDetail.loopFailure">
        <tc:out value="${pageDetail.loopFailureDisplayString}" />
    </tc:forEach>
</tc:if>

TCLTimeEntrySYS (newer style)

A time entry tool demonstrating the newer EL-based syntax with v1.0 namespace.

Pattern: Uses test= with EL syntax, tc:date for date pickers, tc:select for dropdowns, blockValues for form fields, dynamic columns via tc:forEach.

<tc:select id="showList" list="${pageDetail.showList}"
    name="blockValues['ShowSelected']"
    onChange="invokePageDetailAction(this, 'showList', 'populateTaskList()');" />

<tc:date id="timePeriodDate" name="pageDetail.timePeriodDate" />

Screen Designer example (v4.0)

<?xml version="1.0" encoding="UTF-8"?>
<tc:transform xmlns:tc="http://www.mitratech.com/schemas/2008/custom" version="4.0">
    <tc:useClass name="KeyDatesTimelineBlock" id="cjb"/>
    <tc:blockTemplate blockTitleKey="custom.common.KeyDates.BlockTitle" showEdit="false">
        <tc:if test="${!enterpriseEntity.newEntity}">
            <tc:out value="${cjb.myData}" />
        </tc:if>
    </tc:blockTemplate>
</tc:transform>