Modules layouts

Module Suite's modules present a peculiar layout that differentiate them from most of the Content Server's modules you might have worked with. Knowing the modules' internal structure is of primary importance when it comes to: upgrading, maintaining or extending your Module Suite instance.

Content Script

Content Script features a set of layout differences in respect to standard Content Server modules. In the following paragraphs each one of these differences is discussed in details.

amlib

The “amlib” directory contains all the core libraries of the Content Script Java Layer. It is also used to deploy and manage Content Script Extension packages. If a Content Script API Service (CSAS) , made available from a CSEP, needs to load its own Java libraries, then they will be deployed in a sub-directory of the amlib directory having the same name of the Content Script API Service identifier. This way, two different Content Script API Services can load two different version of the same Java library.

csscripts

Content Script scripts can be used and also invoked directly from OScript. Scripts under this folder can be executed as part of OScript scripts or functions. Some of them are used to implement Module Suite’s administrative pages.

The Content Script OScript APIs are not covered by this training manual.

library

Module Suite's components behaviour and functionalities can be modified and extended by manipulating the content of the Content Script Volume (a Content Server’s Volume created when installing the Content Script module).

The purpose of most of the structure and content of the Content Script Volume can be easily understood by simply navigating the volume thanks to the "convention over configuration" paradigm that has been adopted. That means that most of the time, simply creating the right Content Script, Template Folder or Template in the right place will be enough to activate a specific feature. The default configuration (i.e. the default Content Script Volume's structure) should be imported as part of the installation procedure of the Content Script module.

In the next sections we will refer to specific locations in the Content Script Volume content as "Component Library" or simply "Library". This directory contains the default initial version of the Library and will be used later on to manage Library’s backups and upgrades. The Library can always be imported, exported or upgraded directly from the Module Suite’s administrative pages.

override

Content Script can be used to deeply customize the Content Server standard UI through a non-disruptive (applying non-permanent modifications) functionality that allows developers to override the standard result of a Content Server weblingo file evaluation with the result of a Content Script execution.

Weblingo override functionality is controlled by XML configuration files to be placed in the " override" folder in the anscontentscript module.

<?xml version="1.0" encoding="UTF-8"?>
<override>
    <active>false</active>
    <target>
        <![CDATA[E:\OTHOME\module\webattribute_10_5_0\html\attrstring.html]]>
    </target>
    <!-- Content Script ID -->
    <script>ID</script>
    <!-- BEFORE, AFTER, CUSTOM -->
    <mode>CUSTOM</mode>
    <!-- Optional Script's Parameters -->
    <params>
        <entry>
            <key>key</key>
            <value>value</value>
        </entry>
    </params>
</override>

Within the folder, you should find a sample XML configuration file that should be quite self-explanatory. The XML file points to a Content Script object, identified by dataID, which implements the functionality.

Setting the "active" flag to "true" will activate the override. 

Please note that this is a very low-level functionality and such might have a significant impact on users' experience use it with caution. The feature requires a restart every time the configuration is changed.

Beautiful WebForms

The most relevant aspects of the module's internal structure for the Beautiful WebForms module are related with the "support" directory. Beautiful WebForms default View Templates make use of several JavaScript libraries: they have been selected, written and optimized to work together with View Templates.

In particular, the Beautiful WebForms’ unique validation framework makes use of the libraries stored under the "js" directory. The recommended way to load these libraries is to make use of the Velocity macros expressly designed to load them

Starting with version 2.0 the module's static resources have been deeply revised and re-organized. They are now structured in a way that reflects the way Beautiful WebForms' widgets are organized in the Content Script volume. Beautiful WebForms' widget are in fact now organized into libraries. V2 is the default library used since version 2.0.

Script console

The Script Console internal structure reflects its ability to connect to multiple Content Server Instances and to organize Content Script scripts in multiple repositories.

Since version 1.7.0, the Script Console runtime and configuration folders are all stored under the same installation path. The Script Console installation folder will appear as shown in figure here below:

Script Console main configuration file

The Script Console main configuration file (cs-console-systemConfiguration.xml) is stored under the config directory. As the naming of the file tells us, it is an XML based configuration file, intended to include general configuration parameters of the Script Console as well as specific settings related to the Content Server system to which the Script Console can be connected.

The configuration file is automatically modified by specific actions performed on/through the Console (such as registering a new target Content Server system) or can be edited manually by the administrators.