MADCAT runs workspaces. A workspace is a set of 4 major types of elements : Models, Types, Renderers and Tools.
In addition the workspace contains secondary elements like : folders for data storage, bitmaps, stylesheets, etc...
Workspaces are defined by XML files with extension XWS. Files are called "workspace definition files".
MADCAT can be associated to XWS files to run directly workspaces from the Windows explorer. Otherwise a startup menu let you choose the workspace to run.
A XWS file defines :
So let's start with the Workspace Editor. Our work will be divided into 2 main work packages :
Your mission is to built an application which will help you create new applications ! We want something that will produce new workspaces without having to write XML files.
First, build the workspace of this application. Then, take a look to the API to develop the tools which will generate new workspaces.
First we need to create a folder for our workspace with specific sub-folders inside. The mandatory sub-folders are :
It is recommended to add the following folders :
Create a text file named "Workspace.xws" in the root folder of your workspace and type the following text inside :
Now, the application can be started by doucle-clicking the XWS file in the Windows Explorer :
The model is a database definition. It explains MADCAT how data is organized, how it should be presented to the user (input forms, display sheets, etc..) and how users can interact with the data. Models are defined with XML files. One model defines one database. Databases are made of :
A workspace can manage more than one model. Using links, models can share data without duplicate.
All the data produced with one model is stored in one XML file.
We'll start by creating the model of the XWS files.
Download the file below and place it in the folder "Models" with the name "workspace.xml"
Download the file below and place it in the folder "Models" with their original name :
Now, place these additional bitmaps in the "Bitmaps" folder :
An item is an XML element. In our example, items are defined in the models :
They can be created, edited and deleted with the toolbar of the model explorer of MADCAT :
Atomic piece of data. Owns the values attached to an item. Attributes may have various types; each type is linked to a default input field and display format.
MADCAT manage the following types :
The form is generated using the parameters defined in the model. MADCAT creates one field per attribute in the edit form of an item :
Each value of an attribute will be stored in a real XML attribute of the XML element created in the project data :
Triggers are actions performed automatically when end-user executes a specific action on an item.
Triggers are attached to items in models. Possible triggers are :
Actions are threads executed by the tools of your workspace. They can be run by clicking a button on the tool bar of MADCAT or activating a trigger. By defaut, MADCAT provides no tools. Only advanced users can create their own tools by using the API of MADCAT.
MADCAT allows the end-user of a workspace to enable/disable a trigger. Future releases of MADCAT will restrict this possibility by using access rights attached to end-users.
ACTIONS are XML child elements of ITEMS and FOLDERS which indicate the name of the action a user can perform on them.
The actions are implemented in tools. The name specified in the ACTION element must be one of the names defined in a tool definition file of your workspace. If the name refers to an action performed by a tool which is not loaded (unknown action name), the element is discarded without any messages.
This attribute controls the buttons of the tool bar of MADCAT where actions of loaded tools are displayed. When the end-user selects an item in an explorer, only the actions listed with this element in the model of the item are enabled. All the buttons of other actions are disabled. The contextual menu of the explorer is updated as well.
Links are specific items that allow items to have children coming from external database of the same workspace.
They are defined in a model by using the LINK element. When MADCAT find a LINK element in an ITEM or FOLDER element, the user will be able to create links in this ITEM or FOLDER.
In this example, the model is designed such as the user will be able to create links to renderers in the folder "Renderers" of the item "Workspace" :
This element defines a special folder which doesn't contain items you create manually. It contains items found by executing a standard XPath expression on the current database.
The items listed by queries can be modified or deleted. Just note that they are not real XML children of the "Query" element.
A folder is a XML element which can contain one or more elements such as : items, folders, queries.
The difference between ITEMS and FOLDERS is FOLDERS have only one attribute named "NAME".
MADCAT manages two types of folders :
When defined by the model, folders are automatically created by MADCAT when the parent of the folder in the model is created by the user. The XML element attached to the folder in the project's data has its name specified in the model. They are seen as static parts of the parent item. Such folders can't be deleted, moved or created by the end-user. They can also be attached to actions with the ACTION element.
When created by the end-user, the folders can be deleted, moved, created anywhere in the data hierarchy. The XML element associated to them in the project's data is always named "FOLDER". Concerning triggers and allowed actions, they automatically inherit their parent's properties.
In addition to the base types of MADCAT, advanced users and workspace suppliers can create their own types.
Base types are :
When defining a new type, you have to handle the format, display and conversions of the values assigned with this type.
The API of MADCAT defines interfaces to control types and allow sorting, filtering, display and conversions.
Boolean input fields have now several new options :
Numeric input fields have now new display options :
To help you try the parameters settings and all the types of MADCAT, I made a demo workspace which allow you to create items having all the different input fields offered to you by MADCAT.
Download and unzip the following package, then run the workspace by double-clicking the XWS file.
In the future, a complete documentation will be available. But for the moment, just use the model written in this demo workspace to find the options you can use to build your own workspace.
Renderers are libraries (DLL) which provide new controls to display/edit your data. The controls are embedded in the explorer window of MADCAT.
They are written in C++ using the assemblies of MADCAT.
One renderer can manage many modes. End-user can attach a specific renderer and a mode to an item in a model. He can also change the mode or the renderer directly in the database explorer.
Renderers can also manage user options like tools.
There are no restrictions on the controls used as long as the following objectives are satisfied :
End-user can switch from one renderer to another by clicking on buttons in the explorer tool bars.
MADCAT provides only one renderer by default. It is directly embedded into MADCAT's executable file. It is not a DLL.
This renderer supports 5 modes :
The definition file is a XML file which comes along with the library (DLL). Its extension is XRD.
It is read by MADCAT during start-up. It contains important elements :
These information are used by MADCAT to display renderer's buttons into explorer windows of the user interface.
Each renderer can implement one or more rendering modes. Modes change the style of the display. End-user can change the mode by clicking on the drop-down button of the renderer in the explorer tool bar. The modes are defined in the renderer definition file (XRD).
Renderers can also integrate new buttons in the explorer tool bar to add new features or control the display.
Renderers can also define a set of parameters which can be changed by the end-user in the "Options" form of MADCAT.
These parameters can control the behaviour of the renderer.
Workspace suppliers can also define rendering options in their models. ITEM and FOLDERS has specific attributes to control the renderers. With these attributes, you can automatically switch to a specific renderer and a mode when the end-user "opens" an element in an explorer window.
Tools are programs which can perform treatments on the data of a workspace. One treatment is called an "action".
They can be external programs (.exe) or user-specific libraries (.dll) compatible with models.
Tools are developed by workspaces suppliers. MADCAT has no tools by default. They are based on the API of MADCAT and the .NET framework of Microsoft.
They can access data to create/edit/delete items in your project. But you can also use them to perform treatments on files by using the powerful set of libraries of the .NET framework.
A tool can offer several actions. Actions are attached to items by the model (see ACTION). End-user runs them through the menu or the toolbar of MADCAT's interface.
Tools and their actions are defined in a XML file with extension XTL.
Task management
MADCAT provides a powerful task manager and log manager to execute tools' actions in different threads and trace any events or changes performed to the data. Actions can be scheduled, paused, resumed, canceled, re-run, and so on... in a very easy way.
All database updates are traced and can be checked after action's execution. Transactions can also be canceled when action fails to preserve the database.
Progress display
MADCAT provides to the end-user a very detailed progress window providing global progress, estimated end time, step progress and controls for action execution.
Logbooks
It also provides a logbook system which allow the end-user to capture all events and messages produced by the tools or only specific ones using filters. Logbooks can be exported, transformed in HTML because they are also XML files.
User preferences
Finally, MADCAT provides a user profile management which allow tools to define sets of options users can change freely. Options are automatically saved when user leaves MADCAT and loaded when he enters a workspace.
Each workspace has its set of options. Options are user-dependent (saved in the Windows's user-specific folders)
Practically a tool is a DLL (Dynamic Link Library) with a definition file having a XTL extension. This definition file controls the way MADCAT displays and executes the actions supported by the tool : it gives the following information :
Execution of actions can be controlled by several parameters :
These settings are defined once for all by the designer of the tool. Changing these settings without changing the tool itself may produce unpredicable results.
You can download the definition file of the tool used by the workspace editor :
WorkspaceEditorTool.xtl
All actions are controlled by the process manager of MADCAT. The process manager provides a list of the actions performed or in-progress. Using the process manager, you can :
Depending on actions' parameters defined by the XTL file, the end-user can pause, resume or cancel a running action from the process manager window or from the progress window of the action.
Each action has its own progress window which can be displayed or hidden at any time.
MADCAT also indicates the number of running processes and the overall progress in the title bar and status bar of the main window.
MADCAT records several information about each action :
All this data can be analysed in the execution log window :
MADCAT can manage baselines of your data. Baselines can be seen as read-only snapshots of your data. Once a baseline is closed, the data is saved at the time of closure. You can continue modifying your data but you will always be able to see it at the time of baseline's closure.
It can show you dynamically the changes made between baselines with colors.
With the menu "Baselines", end users can also easily navigate through baselines and compare them by changing the reference baseline. Create new baseline from any existing baseline (create a new branch)
The history of changes performed in a baseline is saved in a baseline file (Extension is XBL). A baseline file can be loaded at any time. It is also an XML file which can be used to perform analysis and reporting.
By switching from one baseline to another, you can produce a version tree like this :
Baseline mechanism can be activated or deactivated at any time by modifying the workspace definition file.
Report is a XML file which defines a standard XPATH query to execute on the databases of a workspace and a XML stylesheet (XSLT) for formatting. Extension is XPT.
The ouput can be HTML or XML. End-user can save it into a file.
Reports can use input parameters to control the content of the report : the values of the parameters are used in the XPath expression.
For example, the Report definition defines one parameter :