Extension files
To make use of Roomle's wide range of UX functionalities, it is necessary to add information to the IDM export (the xml file) as those informations are not part of the IDM format. This additional information can be provided via extension files (*.csv) as defined below.
Catalog definitions
File: catalogDefinition.json
Contains global data regarding the catalog.
priceLists
defines a list of countries for which the prices in this import should be used. "default" adds the prices to the default-list which is used by Roomle if no price is set for the current country.
activateIDMMasks
(default: false) defines if the dockmaskhandling via IDM features (AVx values) should be activated.
materialFeatures
(default: list of color features for IDMK, empty for IDMP and IDML) defines the list of features that must be considered as material features.
Translations
File: translations.csv
To make translations reusable, its possible to provide one global translations file. This file can contain labels in multiple languages for a list of translationKeys. Those keys may then be referenced in other extensionfiles to use these translations
Parameter groups
File: parameter_<SeriesID>.csv
IDM does not include a concept of grouping parameters. There are FeatureClasses but they are only structural definitions without labels etc. Therefore they cannot be used for the Rubens UI.
To make use of Roomle's parameter groups, you must provide an extensionfile including the following information:
First block (identified by a line starting with
internalGroupKey
): defines all wanted groups. Each group is defined by a internalGroupKey, which is preferably an english word, a parameter group label, the respective translations and a sort number (optional). If no sort-value is provided, the position in the block is used.Second block (identified by a line starting with
parameter
) defines the parameters with their logic overrides and group connection. The columnparameter
can include the label of an IDMFeature or the IDMFeatureNumber (recommended) itself. Within the next two columnslocal
andglobal
the parameter levels can be overriden.internalGroupKey
defines to which group the parameter belongs. IndefaultValue
a default value for this parameter can be set. This value must be an idm optionKey (can include spaces). The value will be processed as all optionKeys are (spaces and some special characters removed etc.). Please note that there exists idm logic to set the default value via decisions. This logic is not affected by this setting.
Merging to type-objects
File: metacomponents_<SeriesID>.csv
IDM includes all objects as seperate items. For usability it is often useful to combine them together for an easy switch in the interface. For this two levels of combination are provided: Merging IDM items together by types (idm-type or customType) and then combining a list of types to one metacomponent.
First block (identified by a line starting with
componentId
) contains the metacomponents that should be created. Each line defines one such component with the elements as idmTypes (and all following columns) defining what types should be merged.
Types can either be the type number of an idmType or a reference to a customType defined in the ...
Second block (identified by a line starting with
customType
) contains a list of custom types. Each line defines one customType with the type identifier, possible labels for the type and the list of models (columnmodells
including all following colums) which belong to this type. The order in which the modells are shown in the modellParameter of the created type-component is defined by the order how the modells appear in this list.
Custom dock mapping
File: dockings_<SeriesID>.csv
With this file you can change and extend docking-definitions from IDM. It is possible to map an IDM dockpoint to another dockpoint (f.e. AVC1 to AVL). This will keep everything else untouched and only switch the dockmask of the roomle-component to the according mask. Therefore it is possible to have multiple dockings with the same "IDM-mask" in rml. f.e. when there is already an AVL and you add a mapping of AVC1 to AVL. It is also possible to restrict the mapping to being only a parent or a child-docking by adding _parent
or _child
to the target mask. In this case, only the defined version of the docking will be added to the component.
In general, the mapping applies to the whole series unless restrictedToItemIds
is set. If the mapping is restricted to IDM itemIds, only those items are affected by the mapping.
It is also possible to define a flipped version as the input by adding _flipped
to conversionFrom. In this case the resulting docking takes the AV-line from the SVG in the opposite direction for the conversion to roomle. Flipping is only supported for AVC dockings
It is not possible to map one IDM docking to multiple rml dockings within one IDM Item. Meaning you can't create f.e. an AVL and an AVR from one AVC02. It is only possible to us an AVC and a flipped AVC for different target dockings.
additionalCondition
can contain a roomle expression which is added to the generated conditions of the dockpoints in the roomle script. The resulting condition will be (<additionalCondition>) && (<other generated conditions>)
. If there exists an item-restricted adaption for a dockpoint, all additionalConditions for this dockpoint in this series (even for items who use a non-restricted mapping) are evaluated within the onUpdate of the component. For dockpoints without item-restrictions, the additionalCondition is evaluated in the dock-condition directly. So only in this case have you access to the connection context. This is necessary cause different types might have different conditions.
shouldPropagateAVValueChange
defines if this dockpoint should be able to set the AVValue on the other side. This happens if parameters get changed such that the current masks don't fit anymore and the docked component would need to change. If this is not wanted (aka if the other side should not be changed) then this needs to be set to false
. Default is false for al AVUs and true for everything else. Empty means the default is used.
Last updated