TSearch Components

Following are definitions of the fields that make up each TSearch section as well as an example of each JSON script.

Overview of Terms

Template: As the name suggests, a template for a View. Templates contain restrictions on what sections appear in the page as well as what type and how many widgets can be placed in them.

View: A representation of a template. TSearch views require a Search Connection to function.

WidgetDefinition: Acts as a template for a WidgetInstance. Defines configuration to use when constructing a WidgetInstance.

WidgetInstance: A representation of a WidgetDefinition with configuration. There can be an unlimited number of instances of the same definition.

Templates

pageTitle: The default page title for views created with this template.

shortName: Used as part of a view’s url to direct which resources to load.

In a development context, also called templateId and can be used in widgets to alter behavior. For example, a number of widgets act differently if a shortName ends with “rm”. [put a link to later section where we do template deep dive]

displayName: The display name for the template in the Simflofy Admin UI

defaultSchema: The default security schema for a template. Can be READ_ONLY, EDITABLE, or OPEN. See the Permissions documentation for more information.

sections: Each template contains sections. In practice these are a <div> object with a specific id. Many widgets build themselves onto their designated section. Sections are their own entity with the following properties:

maxWidgets: The number of widgets the section can contain.
acceptsWidgets: What types of widgets can be placed in this section
displayName: The section name in the view builder
shortName: Section shortName for development purposes
defaultWidgets: A list of widgets that are required for the view. There is an option to create these widgets when creating a new view. Otherwise, Simflofy will grab the first available instance.

Sample Template


{
 "sections": [
   {
     "maxWidgets": 8,
     "acceptsWidgets": [
       "ANALYTICS",
       "FACET_SEARCH"
     ],
     "shortName": "left_sidebar",
     "displayName": "bootstrap.template.simflofy.left_sidebar",
     "defaultWidgets": [
       "FullTextWidget",
       "CurrentSearchWidget"
     ]
   },
   {
     "maxWidgets": 15,
     "acceptsWidgets": [
       "RESULT_SET",
       "PAGINATION",
       "CONTENT_ACTION"
     ],
     "shortName": "body",
     "displayName": "bootstrap.template.simflofy.body",
     "defaultWidgets": [
       "ResultWidget",
       "PagerWidget"
     ]
   },
   
 ],
 "pageTitle": "bootstrap.template.simflofy.pt",//represents an i18 string in a property file
 "shortName": "simflofy",
 "displayName": "bootstrap.template.simflofy.dn",
 "defaultSchema": "READ_ONLY"
}

Content Views

id: timestamp id for the view

connectorId: The connectorId for the search connection used to retrieve results

displayName: The page title and display name in the Simflofy UI

owner: The creator of the widget

shortName: The shortname of the view. Will be used in conjunction with the template name to load the view in tsearch using the form tsearch/view/[template]/[shortname]

template: The template in use

qload: Whether the view will execute a query on a page load. Note that afterRequest() methods will still trigger even if this is false, as some widgets need all other widgets loaded before they can start working.

isRM: Whether the view will be grouped with RM related views in the TSearch dashboard

schema: The current schema in use

Sample Content View

{
    "id":1603728142688,
    "connectorId": "elasticrm",
    "displayName": "RM Dashboard",
    "owner": "admin",
    "roles":
    {
        "widgets": [
        {
            "action":"1608574466195",
            "allow": false,
            "principals":["everyone"]  
        }],
        "admins":["admin","user2"],
        "users":["Product Testing"]
    },
    "sections": [
    {
        "displayName": "Body",
        "shortName": "body",
        "widgets": ["1603817210063", "1604594709824", "1611330558892", "1625141063436", "1608574466195", "1608575442756"]
    },
    {
        "displayName": "Top Menu",
        "shortName": "top_menu",
        "widgets": ["1603722607642", "1607544997324", "1609945412988"]
    }],
    "shortName": "rm",
    "template": "rm",
    "qload": false,
    "isRM": true,
    "schema": "OPEN"
}

widgetId: The “Class Name” of the widget. Used as a constructor as well as a primary key between a definition and an instance.

description: The description of the widget that appears in the UI

widgetType: Can denote a widget's purpose, but can also just denote what section it can be added to.

restrictable: Whether a widget can have its usage restricted. See permissions documentation.

action: (optional) A REST method (POST, PUT, GET, DELETE) which describes the type of action the widget performs. Used by the security schema to determine basic restrictions on who can use the widget. See permissions documentation.

templates: What templates can use this widget.

defaultLabel: (optional) The default label used when Simflofy generates this widget automatically.

customFields: Custom fields are how special configuration can be added to a widget and contain the following fields:

defaultValue: The default value of the field when an instance is created.

fieldName: How the field name appears in code

fieldType: INT or STRING

description: The description of the field in the UI

Sample Widget Definition

{
 "customFields": [
   {
     "defaultValue": "10",
     "fieldName": "maxFiles",
     "fieldType": "INT",
     "description": "Max queued files"
   },
   {
     "defaultValue": "5",
     "fieldName": "parallelUploads",
     "fieldType": "INT",
     "description": "Max Parallel Uploads"
   }
 ],
 "widgetId": "DragAndDropWidget",
 "description": "Adds Drag and Drop functionality to the view",
 "widgetType": "TOP_MENU",
 "restrictable": true,
 "action": "POST",
 "templates": [
   "simflofy"
 ],
 "defaultLabel:": "bootstrap.wi.18.label"
}

name: The name as it appears in the Simflofy UI

label: Varies based on widget type, but for the above example, the text that will appear in the Document Actions menu. Default to ‘na’ if no label is required

field: Some widgets search on a specific field. For example, a widget may focus specifically on the file name of a document. ‘na’ for non-search related widgets

widgetId: The widget definition

widgetInstanceId: Randomly generated unique id for this widget instance.

restrictable: Copied from widget definition

type: Copied from widget definition

action: Copied from widget definition

customFields: Copied from widget definition, except “description” is replaced with the value of the field.

Sample Widget Instance

{
 "name": "Delete Documents",
 "label": "Delete Documents",
 "field": "na",
 "widgetId": "DeleteDocumentWidget",
 "customFields": [
   {
     "defaultValue": "true",
     "fieldName": "bulk",
     "fieldType": "STRING",
     "value": "true"
   }
 ],
 "widgetInstanceId": "58863896",
 "restrictable": true,
 "type": "content_action",
 "action": "DELETE"
}

Widgets

Widgets work from a basic template written in JavaScript.

For example:

TSearch.AWidget = TSearch.AbstractWidget.extend({
        init: function () {

        },
        afterRequest: function () {

        },
        beforeRequest: function(){

        }
    })

AbstractWidget: supplies the above methods as well as the doRequest() method, which will trigger a search.

init(): Should contain logic to set up handlers for static elements of the widget. If the widget has an associated modal, set those up here. Can also be used to construct UI elements such as sidebar panels or tabs depending on the widget.

afterRequest(): Takes place after a search response has been handled. Use this method to run through all of the retrieved documents in the page and provide individual functionality per document.

beforeRequest(): Rarely used, but triggers before request. Useful if you need to make sure parameters are set correctly or removed before the search executes. Widgets are instantiated using the following form in tsearch-ui.js

let w = new TSearch[widgetId]();

They are then added to the TSearchManager using the addWidget(w) method, which catalogues them on the manager and calls the init() method. The manager is also attached to the widget, allowing you to access it through Manager or this.manager. More on that later.

Widget Modals

If a widget uses a modal, the modal must be added to the index.html page for the template. If using a modal, it's usually best to have a method to clear field values and hide form controls. Binding this method to the hidden.bs.modal event on the modal makes for quick cleanup.

Data Attributes

The results widgets for the rm and simflofy templates make use of data attributes in html. In practice, it looks like this:

<div data-hold="true"></div>

These fields store relevant data for quick access. Using the JQuery $.data() method in widget development can also help speed up the process. In the template, this is the html of the row for a single document (Note some css has been removed for readability)

<div class="row selerow" data-target="9ec6ce4b-a8d6-48c-abfc-998c81e7a042" data-connid="spo" data-hold="false" data-rm="false">
    <div class="col-sm-1"><input type="checkbox" id="check_0" class="check_down ml-2" name="" value=""><br><img src="/tsearch/resources/styles/images/filetypes/pdf.gif"></div>
    <div class="col-sm-6">
        <h3 title="Phishing.pdf"><a class="titleblock" id="title0">Phishing.pdf</a>
            <p class="desc">spo<br></p>
        </h3>
    </div>
    <div class="col-sm-2 icons" id="icons0"></div>
    <div class="col-sm-3 dropcol" id="dropcol0">
        <div class="dropdown float-right"><button class="btn btn-orange btn-responsive dropdown-toggle" type="button" data-toggle="dropdown" id="actBtn0">Document Actions</button>
           <div class="dropdown-menu" id="actMenu0">
            <button type="button" class="dropdown-item" id="docMeta0">Document Metadata</button>
            <a class="dropdown-item" href="/tsearch/get/simflofy/simflofyrm?req=/repo/spo/file?id%3D9ec6ce4b-a8d6-483c-abfc-998c81e7a042" id="docDown0">Download Document</a>
            <button data-toggle="modal" class="dropdown-item" data-target="#modal_version" id="ver0">Document Versions</button>
        </div>
        <div class="dropdown float-right"><button class="btn btn-blue btn-responsive dropdown-toggle" type="button" data-toggle="dropdown" id="rmBtn0">Records Management</button>
            <div class="rm dropdown-menu" id="rmMenu9ec6ce4b-a8d6-483c-abfc-998c81e7a042"><button class="dropdown-item addbtn" type="button" data-toggle="modal" data-target="#scheduleModal">Add Retention Schedule</button><button class="dropdown-item actionbtn declarebtn" data-action="declare" type="button" data-toggle="modal" data-target="#scheduleModal">Declare As Record</button></div>
        </div>
    </div>
</div>

The first important thing to notice is the first row. It has number attributes on it that should be self-explanatory. Many operations in TSearch are performed by selecting on data-target, as it is always going to be the docId or recordId of a row, depending on the template.

Also, the document actions and rm menus have numbered ids for quicker retrieval as well.

If the RM Results widget has been added the RM dropdown will have an id of rmMenu+docId. Additionally, a number of attributes around disposition steps will be added to each row.

Finally, not pictured, is the “pos” data attribute accessible through $row.data(‘pos’), which is simply the documents index in docArr.

The rm template has a slightly different structure but follows the same general idea in terms of what data is stored on the row.

Overview of Terms​

Templates​

Content Views​

Widget Definitions​

Widget Instance​

Widgets​

Widget Modals

Data Attributes​

Overview of Terms

Templates

Content Views

Widget Definitions

Widget Instance

Widgets

Data Attributes