Version 3.0.0 (Generoso) - Release notes¶

(*) Active Maintenance Period

The present document contains information regarding product enhancements, fixed issues and known issues related to AnswerModules Modules Suite version 3.0.0.

Module Suite Compatibility Matrix¶

Major Changes in version 3.0.0¶

IDEs¶

All the Module Suite's IDEs have been deeply revised. Among the new functionalities introduced: filtering for snippets and widgets, editor theme selector, log level rapid switch for Content Script Editor, remote repositories for Content Script snippets, Content Script Co-edit (Beta)

Filtering¶

A new filtering feature has been added to all IDEs to make it easier to select the appropriate widget or snippet in large libraries.

Remote snippets repositories¶

You can now retrieve Content Script snippets from remote repositories. This allows you to maintain an enterprise KB related to Content Script (in the form of a local Snippets repository or leverage Snippet repositories offered by third-party vendors. To register a new repository you need to add a custom option in Base Configuration having the form: amcs.msrepo[n].url =Label|repoUrl where n is a number between 0 and 10.

amcs.msrepo0.url=Sandbox|https://developer.answermodules.com/resources/repos/sandbox

Concurrent Script Editing¶

Module Suite 3.0 features an experimental functionality that allows several developers to simultaneously collaborate on the editing of the same script. The functionality leverages WebRTC to establish a peer-to-peer direct connection among developers. The developer's browser will connect to the specified signaling server to find other peers. A password can be specified to encrypt all communication on the signaling server even if no sensitive information (WebRTC connection information, shared data) is shared over the signaling server.

Content Script¶

Updated of all major dependencies to their latest releases. New APIs for creating and manipulating OTEmail objects and OT Pulse comments. Improvements to performances related to the retrieval of information from the database.

Administration¶

New performances tuning options available in the Module Suite base configuration.

Beautiful WebForms¶

New V5 library¶

Module Suite 3.0 introduces a new widget libary based on reactive components (Vue.js). With this library, the already powerful engine, used to perform server-side rendering of forms' views is complemented by a reactive framework operating directly in the user's browser. When a form's view is composed using this library, the data model that is normally used in server-side rendering (form) is also serialized into a JSON object on the user's browser. This client side "model" feeds a reactive application developed with Vue.js. Thanks to this new approach we open up the possibility of performing numerous manipulations of the data model directly on the user's client.(i.e. it is no longer necessary to perform a client-server round-trip to manipulate the data-model), which do not longer require to update (totally or partially) the page containing the view. To support and facilitate the manipulation of the data model on the user's browser, the concept of action, already in use for server-side manipulation of the data model, has been extended and revised. When an action is now triggered the frameworks looks for its implementation first in a client-side registry, and only if it is not found proceeds invoking the server-side business logic (CLEH). The implementation of a client-side action is pretty simple and can leverage a dedicated javascript API, whose main methods are:

form //represents the form object (as in CLEH scripts)
form.validate() //Triggers form validation
form.getFieldReference(index, fieldName) //Access the input widget associate to a specific form's field.
                                         //fieldName is the field's path in the form (e.g. MySet:MyField)
                                         //index represent the set row
form.viewParams // The viewParams variable as in CLEH scripts
                // e.g. form.viewParam.vmVar
form.submitForm(withValidation) //Submits the form eventually triggering the form's validation first
form.getFieldValues(fieldName) //Retrives the list of values for the given form's field
form.getViewParamsValue(viewParamName) //Retrieves the value associated to the given viewParams's variable 
                                       //The main difference between form.viewParams.myVar and form.getViewParamsValue('myVar')
                                       //is that if myVar contains an object having the following structure:
                                       // {ajax:{url:"https://some.service.com/endpoint", data:[]}}
                                       //the API form.getViewParamsValue('myVar') automatically fetches the information from the
                                       //remote service and caches the result in the objects 'data' propoerty which is ultemitely returned
form.setViewParamsValue(variable, value) //Set the value of a viewParams variable
form.setFieldValues(fieldName, values) //Set the values for the given field
form.setFieldReadOnly(fieldName, values) //Set the field as read-only or editable 
form.addField(fieldName, index) //Adds an instance to the specified field
form.removeField(fieldName, index) //Remove an instance to the specified field
form.addConstraint(fieldName,contraint, configuration) //Adds the specified validation constraint to the given field
form.removeConstraint(fieldName, contraint) //Removes the specified validation constraint to the given field

New widgets for library V4¶

Added new widgets in library V4

Smart Pages¶

Commands definition cache¶

It is now possible to cache (using the distributed memcache) the result of the execution of the scripts stored under "CSSmartView:Commands" used to load the definitions of the additional commands you want to be available in Smart View pages. The scripts outcome is cached on a per-user basis. To enable the caching set to true the "amcs.amsui.volumeCache" parameter in Base Configuration. To programmatically clean the cache use the amsui.clearCache() API.

Actions definition cache¶

It is now possible to cache (using the distributed memcache) the list of scripts under "CSSmartView:Actions" used for lazy loading additional commands in the Smart View pages. The scripts list is cached on a per-user basis. To enable the caching set to true the "amcs.amsui.volumeCache" parameter in Base Configuration. To programmatically clean the cache use the amsui.clearCache() API.

Overrides optimization¶

The internal mechanisms related to how the customizations are applied to the menus and the columns of the browsing pages of the Smart View interface have been deeply revised. The content of the Overrides folder is now used to compute an Override Map (OM), specific to your repository, having the following structure:

OM = [
    "globals": [            (1)
        540588              
    ],
    "type": [               (2)
        "144": [            (3)
            548066
        ]
    ],
    "tenants": [            (4)
        "497147": [         (5)
            "globals": [    (6)
                548169
            ],
            "type": [       (7)
                "144": [    (8)
                    496932
                ]
            ],
            "ids": [        (9)
                "496931": [ (10)
                    545972
                ]
            ]
        ]
    ]
]

where:

• (1) identifies a list of scripts to be always executed
• (2) a list of scripts to be executed only if the current space has at least one node having of the identified type (3)
• (4) scripts to be considered only if the current space is descendant of the specified tenant (5) (a space identified by its DataID)
• (5) is a "tenant" configuration
• (6) identifies a list of scripts that must always be executed if the current space is descendant of the specified tenant (5)
• (7) a list of scripts to be executed only if the current space has at least one node having of the identified type (8) and is descendant of the specified tenant (5)
• (9) a list of scripts to be executed only if the current space has at least one node having of the identified id (10) and is descendant of the specified tenant (5)
• scripts in the OM are executed in the following order (1), (2), (6), (7), (10).

Given the above example and imagining that all the scripts in (3) (8) and (10) return the list ["comm_one","comm_two"], the resulting AOM will contain:

(3) AOM = [
                ...
                "S144":[commands:["comm_one","comm_two"]],
                ...
            ]
    (8) AOM = [
                ...
                "S144":[commands:["comm_one","comm_two"]],
                ...
            ]
    (10) AOM = [
                ...
                "D496931":[commands:["comm_one","comm_two"]],
                ...
            ]
- scripts in (1), (6), (10) MUST return a Map having entries of the form:
    "SXXXX":[                                                                      
        commands:["comm_one", "comm_two",...],
        columns: [ //Optional                                                       
                    col_name:"col value", //value can be HTML
                    ...
                    ]
    ]
    where XXXX is a valid SubType
    or
    "DYYYY":[                                                                      
        commands:["comm_one", "comm_two",...],
        columns: [  //Optional                                                    
                    col_name:"col value", //value can be HTML
                    ...
                    ]
    ]

where YYYY is a valid node's ID.

OM is to be considered a "static" information in productive environments and as such, to guarantee optimal performances, the framework should be allowed to cached it by setting to "true" the " amcs.amsui.volumeCache" parameter int the base configuration.

When a user changes the current space, the OM is evaluated by the framework against the users' permissions and the actual override map (AOM) associated to the space is determined. AOM is determined by executing the relevant scripts in OM in the order described above. The AOM has the following form:

AOM = [
    "S144":[                                                                       (1)
            commands:["comm_one", "comm_two",...], //list of commands' command_key  (2)
            columns: [                                                             (3)
                        col_name:"col value", //value can be HTML
                        ...
                     ]
           ],
    "D1234":[                                                                      (4)
            commands:["comm_one", "comm_two",...], //list of commands' command_key
            columns: [
                        col_name:"col value", //value can be HTML
                        ...
                     ]
           ]
    ...
]

where: (1) represents commands and columns to be associated to all the nodes having the identified subtype, (3) can be omitted, (4) represents commands and columns to be associated a specific node (identified by its id), (4) takes precedence over (1).

How OM is created ?¶

In order to determine the OM, the content of the "Overrides" folder is evaluated following the logic below:

[
    "globals":[             (1)     
        540588
    ],
    "type": [               (2)
        "144": [            (3)
            548066          
        ]
    ],
    "tenants": [            (4)
        "497147": [         (5)
            "globals": [    (6)
                548169
            ],
            "type": [       (7)
                "144": [    (8)
                    496932
                ]
            },
            "ids": [        (9)
                "496931": [ (10)
                    545972
                ]
            ]
        ]
    ]
]

• (1) Contains the list of scripts objects stored directly under "Overrides"
• (2) For each direct subfolder of "Overrides" that has a name starting by the letter "S" an entry is created in "type" map (2). The key of such entry is the target subtype (as specified in the subfolder's name) while the value is the list of scripts contained the aforementioned subfolder.
• (4) For each direct subfolder of "Overrides" that has a name starting by the letter "D" an entry is created in "tenants" map (2). The key of such entry is the tenant's DataID (as specified in the subfolder's name) while the value is the tenant OM configuration.
• (5) For each "tenant" subfolder a sub-Override Map is created (SOM). The structure of SOM is identical to the one of OM with the only difference that subfolders of a tenant subfolder having a name starting with the letter "D" are used in SOM for creating entries in the "ids" map.

Below an exemplar content of the Overrides folder

and the resulting OM

[
    "globals":[                     
        00002
    ],
    "type": [               
        "144": [            
            00004          
        ]
    ],
    "tenants": [           
        "1234": [         
            "globals": [ ],
            "type": [       
                "0": [
                    00007
                ]
            },
            "ids": [
                "5678": [
                    00009
                ]
            ]
        ]
    }
]

All Enhancements in version 3.0.0¶

Issues Resolved in version 3.0.0¶