imos XML documentation

(1)

Last updated – 12.07.2021

Version:

For B2B systems: iX NET B2B (2019); FE 7.0

For B2C systeme: iX NET B2C (2019); Shopware 6 (min. 6.1.4)

The following document is intended to help you understand and create XML structures.

Notes

• For some features there is a certain NET or Configurator version necessary to use them. Next to the title, there is an information, for example:

(imos NET from 7.0)

. If there is no information, the feature is working in every version. If there is an information but your version is not listed, the function is not available.

• Depending on the NET or Configurator version, the layout and design can be different. These different layouts are part of their respective version and cannot be customized – either update or purchase the NET module “myGUI”.

• While creating XML files you must be careful about all the details in this documentation. The most important detail is the naming of the XML elements. In general, you can define all the names on your own (except for system variables – more information will follow later) and type them in. Each XML elements needs a unique name (like an ID), which is important for referencing. In case duplicate names occur, the system is not able to interpret commands correctly.

We have attempted to keep the content of the document complete, accurate and under permanent review. However, due to the continuous development of described software, it is not possible to guarantee up to date and accurate information, integrity or quality of the content always. As far as we are able to detect errors or omissions or those, which have been reported to us, our attempt is to correct these with the following versions. imos is not responsible for any direct or indirect damages caused by the use or non-use of the presented information or through the use of faulty and incomplete information. The descriptions in this document can be changed at any time without prior notice.

(2)

1. Introduction ... 3

2. Structure of the XML files... 5

Article.xml ... 6

Include files ... 25

1. Advanced Functions ... 26

FINAL_LOGIC_DEFINITION ... 26

GLOBAL and GLOBAL CHANGE ... 27

Infobutton – ToolTip ... 28

NET Panel module (list input) ... 29

Interactive preview ... 31

System variables ... 33

Localization of XML ... 34

Texture_mapping.xml ... 36

Vartext.xlf ... 40

2. Calculation ... 44

Calculation principles ... 45

Overhead/ Discounts for NET B2B Users ... 48

3. Deprecated Features ... 50

3. Appendix – Detailed description of all attributes ... 51

(3)

Introduction

XML data structures and data flows

Each XML file starts with a prolog that gives information about the version and encoding. An XML document consists of XML elements which are nested into each other. Each element can have several attributes, which are following certain rules.

On the top level of the XML file, there can be only one element. In the example below, it is <xml>…</xml>. Each element requires one opening and one closing tag. The attribute values have to be enclosed by quotation marks.

Furthermore, there is a difference between upper and lower case. XML elements can be nested but do mind the order of the opening and closing tags. As the XML language is a meta language there is no restriction on defining your own

“Tags”.

Important note: The XML files for imos NET must be encoded as UTF-8.

Example:

<?xml version="1.0" encoding="UTF-8“ standalone="yes" ?> <!— prolog-- >

<XML> <!— opening tag-- >

<Tag1 Attribut=“content“>

<Tag2> Text </Tag2>

<Tag3>

<Tag4> Text </Tag4>

</Tag3>

</Tag1>

< self_closing_tag />

</XML> <!— closing tag-- >

(4)

Using the NET shop or Configurator requires different kinds of XML files and structures. These are the three main types:

➢ Catalog.xml

(not for imos NET B2C)

–all your products (articles) are listed and categorized in this file. You can individually define the catalog layout and what products should be listed. You can also define product categories where the products should be listed. There is no limit to the number of categories and products.

➢ Article.xml – Each product/ article needs its own article.xml file which is a link to the respective imos article in your database. Just calling the article, usually does not suffice – various article variables must be configurable. So the configuration options are depicted with XML elements as well. It is up to you, which options should be available and to what extent the are configurable.

➢ Include files – The include files will be explained in more detail later on in another chapter. In general, this type of file is for outsourcing XML content into separate sub-files. Example: The XML elements about the material choice is written into an include file; this include file is called in the article.xml. In case there are hundreds of articles using the same material collection, you can simply call the respective include file in all article.xml files. This reduces XML code immensely because the information is managed in one place only. Updates of this XML code affect all articles at same time.

There are other types of XML which are optional. They are described in a later chapter.

(5)

1. Structure of the XML files

Catalog.xml

The catalog.xml depicts the shop catalog. It is up to you how many categories and articles it contains and how they are nested. The file name of the catalog must be unique. For NET shops, name the file with the context number followed by _1 or _2 at the end to distinguish them.

Example: 2000_1.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<catalog name="2000_1" label=”Wood Design Package” image=”img/catalog/Defaultbox.jpg”>

<category name="BC" label=”Base cabinets” image="img/catalog/Defaultbox.jpg" info=““>

<category name="STANDARD" label=”Default” image="img/catalog/Defaultbox.jpg" info=““>

<object model="BC_1SD" name="Article 1" image=”img/catalog/Defaultbox.jpg” info=““/>

<object model="BC_4DR" name="Article 2" image=”img/catalog/Defaultbox.jpg” extLink=”” extLinkLabel=””/>

…

</category>

<category name="TC" label=”Tall cabinets” image="img/catalog/Defaultbox.jpg">

<category name="SPECIAL" label=”Special” image="img/catalog/Defaultbox.jpg">

<object model="TC_1SD" name="Article 3" image=”img/catalog/Defaultbox.jpg”/>

<link name=”imos_link” label=”imos3d” image=“img/catalog/link.jpg“ link=“https://www.imos3d.com“ />

</category>

</catalog>

You can find a detailed description of all attributes in attachment A1

(6)

Article.xml

First of all, the file name of the article.xml must be identical with the name of the imos article. As explained in a prior chapter, this name will be called in the catalog.xml. On this level, it is really just a call for the XML file, not a reference to the imos article. The referencing takes place in the head “<ART_NAME>”.

Overview

<?xml version="1.0" encoding="UTF-8“ standalone="yes" ?>

<XML>

<ARTICLE>

</ARTICLE>

<DEFINITION>

</DEFINITION>

<CONSTRUCTION>

<!—here, we define the links between the imos variables and the input fields of the DEFINITION part-->

</CONSTRUCTION>

<LOGIC_DEFINITION>

<!—here, we define all logical conditions for the user interface -->

</LOGIC_DEFINITION>

<!—here, all other application specific declaration is defined-->

</XML>

ARTICLE

In the article section, the head data of the imos article is specified for its clear identification.

<ARTICLE>

<ART_NAME>Name of the imos article</ART_NAME> 

<ART_TYPE>ANGOLO</ART_TYPE> 

[<ART_INFO_LONG>a detailed description of the article that is shown below the headline</ART_INFO_LONG>]

[<ART_INFO_SHORT>a short description of the article that is shown as the headline in the configurator</ART_INFO_SHORT>]

<ART_IMAGE>file path to the article image</ART_IMAGE>

</ARTICLE>

(7)

DEFINITION

In the section DEFINITION, all input fields are defined. You determine what input fields should be displayed and to what extent/ in which manner they should be configurable: editable text, a drop-down menu, an image selection or via checkbox. When writing this part, please note that the elements will be displayed in the same order that you typed them in, so what you type first will be shown at the top of the NET shop on so on.

With attributes like name=”” you define the XML element in more detail. They play an important role when it comes

to controlling the element and its behavior. You can find a detailed description of all attributes in attachment.

(8)

1.2.2.1 PARAFOLDER

A parafolder is like an index tab and can be named and ordered as you want to. Inside a PARAFOLDER tag, you list all input and output fields (EDIT-, COMBO- and CHECKBOX). At least one parafolder must be listed.

<DEFINITION>

<!— PARAFOLDER is an element that encapsules settings that belong together -->

<PARAFOLDER name=“Unique name of index tab no. 1“ label=“label text to be displayed for this index tab“ visible=””>

<PARAFOLDER name=“Unique name of the index tab 1.1“ label=“ label text to be displayed for this sub-index tab“ ></PARAFOLDER>

<!—PARAFOLDERs can also be nested -->

</PARAFOLDER>

<PARAFOLDER name=“Unique name of index tab 2“ label=“ label text to be displayed for this index tab“ >

…

</PARAFOLDER>

</DEFINITION>

1.2.2.2 Nested PARAFOLDER

(available in imos iX CAD 2019 only; not available in iX NET 2019)

Definition of a tree node. Does not influence the parameter input and evaluation. It should only be used to encapsule input fields that belong together. <PARAFOLDER> definitions can be nested once only.

<PARAFOLDER name=“ Unique name of the node“ label=“ text to be displayed for this node“ visible=“TRUE“ image1=“path-file 1“ image2 =”path-file 2“>

</PARAFOLDER>

You can find a detailed description of all attributes in attachment A2

(9)

1.2.2.3 EDITBOX

The element of type EDITBOX defines an input field where the user can manually enter a parameter as text. The input can be confirmed by hitting ENTER or simply leaving the the field.

<EDITBOX name=“Unique name of the editbox“ label=“field label displayed in front of the field“ min=“minimal numeric value“ max=“greatest numeric value“

default=“a default value“ valuetype=“{TEXT / NUM / LINDIV / DATE}” active=“TRUE/FALSE“ visible=“TRUE/ FALSE “ locked=“TRUE/FALSE“ image1=““

image2=““ info=“additional description”/>

You can find a detailed description of all attributes in attachment A3

1.2.2.4 TEXT

The element of type TEXT is for visualizing text. You can use it to display descriptions or addressing hyperlinks.

<TEXT name=“Name of the text“ label=“ Label text displayed in front of the field“ visible=“FALSE/TRUE“ format=“normal/bold“

address=“http://imos3d.com/” >

You can find a detailed description of all attributes in attachment A8

(10)

1.2.2.5 COMBOBOX

A COMBOBOX offers a preselected set of options that the user can choose from. It can be displayed as a list (drop- down) or a gallery.

<COMBOBOX name=““ label=““ default=““ valuetype=“{TEXT / NUM / LINDIV / IMAGE}“ active =“TRUE/FALSE“ visible =“TRUE / FALSE“

locked=”TRUE / FALSE“ image1=““ image2=““ search = “TRUE / FALSE“ info=“”>

<ITEM value=“value of imos variable 1“ label=“displayed text for imos variable 1“ [info1=““] [info2=““] [info*=““] [visible=“TRUE/FALSE“]/>

<ITEM value=“value of imos variable 2 “ label=“displayed text for imos variable 2 “ [info1=““] [info2=““] [info*=““] [visible=“TRUE/FALSE“]/>

...

</COMBOBOX>

(11)

1.2.2.6 CHECKBOX

Using a CHECKBOX offers the option to select one of two states: checked or unchecked (as shown in the picture).

<CHECKBOX name=““ label=““ default=““ checked=“imos – value1“ unchecked=“imos - value2“ active=“TRUE / FALSE“ visible=“TRUE / FALSE”

locked=“TRUE / FALSE“ image1=““ image2=“” info=““/>

You can find a detailed description of all attributes in the attachment A6

1.2.2.7 GROUP

The element GROUP allows for logical or visual grouping of multiple elements. It is not allowed to group

<PARAFOLDER> because it has nothing to do with the parameter “group” in the input elements!

<GROUP name=“ Unique name of the group” label=“ label text displayed in the frame“ valuetype=”FRAME“ active=“TRUE / FALSE visible=“TRUE / FALSE“>

</GROUP>

Example:

<PARAFOLDER name=“DIMENSIONS“ label=“Article dimensions“ >

<EDITBOX name = „HEIGHT“ label=“Height“ min=“500“ max=“2000“ default=“1200“ valuetype=“NUM“/>

<GROUP name=“GROUP_DEMO“ label=“Width – Depth“ valuetype=“FRAME“>

<COMBOBOX name=“WIDTH“ label=“Width“ default=“120“>

<ITEM name=“100“ label=“100 mm“/>

</COMBOBOX>

<EDITBOX name=“DEPTH“ label=“Depth“ min=“200“ max=“1600“ default=“1000“ valuetype=“NUM“ />

</GROUP>

</PARAFOLDER>

You can find a detailed description of all attributes in attachment A7

(12)

1.2.2.8 Columns

(currently not available in iX NET 2019)

Multiple XML elements of type of EDITBOX, CHECKBOX, TEXT and COMBOBOX valuetype="TEXT/NUM" can be aligned next to each other in a single row. There are two designs available:

1. The label is aligned in front of the selection box, as usual. The width of the elements can be set relative (in percent) to the total width for every child element of the row.

Example:

</GROUP>

2. The label is aligned above the corresponding element. The width of the elements can be set relative (in percent) to the total width for every child element of the row.

Example:

</GROUP>

(13)

Note

All elements of one group should be optimized to fit in one row.

➔ The sum of „width“ has to be <=100%

➔ In case of a width greater than 100% a line-break will split the row The number of elements in a row is not limited.

Using attributes for displaying or hiding such as visible=““ or active=““ is identical in all other groups.

Using MULTIROW will hide the GROUP label.

Element types allowed in a row are EDITBOX, CHECKBOX, TEXT and COMBOBOX valuetype="TEXT/NUM".

Error message order download

To avoid unnecessary errors during order import, variables must not end with “ERROR” because the iBot that parses a PVARSTRING in the order.xml and finds the “ERROR” will interpret it as such.

If you insist on appending “ERROR” to a variable name, please include an underscore “_” at the end.

Wrong:

<CHECKBOX name="NET_IGNORE_SIZE_ERROR" label="{translate:TZTR_001778|Ingnore size errors}" checked="YES"

unchecked="NO" default="NO" visible="FALSE" highlight="error" />

Correct:

<CHECKBOX name="NET_IGNORE_SIZE_ERROR_" label="{translate:TZTR_001778|Ignore size errors}" checked="YES"

unchecked="NO" default="NO" visible="FALSE" highlight="error" />

(14)

CONSTRUCTION

In this part of the XML file, all links are specified between the input fields of the section DEFINITION and the imos variables or the parameters of the construction principles. The construction section is divided into the following parts:

<CONSTRUCTION>

<ARTICLE_CON>

<!—Please define the article dimensions-- >

</ARTICLE_CON>

<VARIABLES>

<!— Please list all variables in use-->

</VARIABLES>

</CONSTRUCTION>

1.2.4.1 ARTICLE_CON

Here, the article dimensions are set via system variables, namely ART_SIZEX for the width, ART_SIZEY for the depth and ART_SIZEZ for the height.

<ARTICLE_CON>

<ART_SIZEX>

<PARAM> name of the field which contains the width of the article </PARAM>

</ART_SIZEX>

<ART_SIZEY>

</ART_SIZEY>

<ART_SIZEZ>

</ART_SIZEZ>

</ARTICLE_CON>

1.2.4.2 VARIABLES

Every input field that should assigned an imos variable must be listed here. In name=““, you type in the variable name, in value=““, you type in the name of the XML input field.

<VARIABLES>

<VAR name="KN1" value ="KN1"/>

<VAR name="MN1" value ="MN1"/>

<VAR name="KIPA_HU_GO" value ="KIPA_HU_GO"/>

</VARIABLES>

(15)

LOGIC_DEFINITION

This section controls the elements/ input fields so that they can influence each other. For example, if a specific

<CHECKBOX> is activated, another <COMBOBOX> will be shown or hidden.

First, all elements are written down in the <DEFINITION> section. With an appropriate logic, you can set elements to visible/invisible, locked/unlocked, active/inactive,… which you declared.

Take into accorunt, that the logic part is processed from top to bottom every time something is changed in the Configurator and that the result can be different depending on the form setup or on how the user fills out the form (filled out in a different oder, entered different values, …).

Example: If the check box is marked with a tick, a drop-down menu for the material choice should appear.

<IF>

<EQ expr1="FIELD(CHECKBOX_MATERIAL_CHOICE).value" expr2="VALUE_FOR_ACTIVE"></EQ>

<THEN>

<COMMAND>"FIELD(COMBOBOX_ MATERIAL_CHOICE).visible=TRUE"</COMMAND>

</THEN>

</IF>

Explanation: Using the <IF…</IF> tags will put logic commands into statements with conditions. The commands will only be executed if the condition in the <EQ>…</EQ> tag (eq=equal) is met (true). The commands to be run are listed in <THEN>…</THEN> tag.

It is also allowed to write only commands with no IF statements. These commands will be permanently active; they

start with <COMMAND> (without IF, EQ and THEN). It is also possible to nest one IF question into another to

implement advanced logic definitions.

(16)

1.2.5.1 Comparative Operators

Comparative operators like <EQ> start a conditional statement. There are six different comparative operators:

➢ <EQ> = (equal)

➢ <NEQ> <> (not equal)

➢ <LT> < (less than)

➢ <GT> > (greater than)

➢ <LTEQ> <= (less than or equal)

➢ <GTEQ> >= (greater than or equal)

For example, calling a comparative operator like <EQ> looks like this:

<EQ expr1=“FIELD(HEIGHT).value“ expr2=“200“/>

For the parameters expr1 and expr2, you can use all operands (see next chapter “Operands”) except for:

„FIELD(name).ItemList(...)“, „FIELD(name).Info1List(...)“ and „FIELD(name).Info2List(...)“.

In this example, we compare expr1, the article height as defined in the corresponding field, with expr2 which is a fix

value of 200: commands following the IF statement will only be run if the article height equals 200.

(17)

1.2.5.2 Operands

Operands can be:

➢ Numbers and text (e.g. „200“,“ „construction shelf“ and so on)

➢ FIELD(name): We use this operand for a read or write access to different parameters/ attributes of a DEFINITION element. Specify the target attribute after the “.”. At the moment, the following attributes are available:

call description access mode

FIELD(name).value Current value of the element. If a Combobox is selected, it will get the value of the current ITEM.

read / write FIELD(name).visible Possible values are “TRUE” and “FALSE”.

If “TRUE” selected, the element will be visible/ displayed.

read / write FIELD(name).active Possible values are “TRUE” and “FALSE”.

If “TRUE” is selected, the element will be transferred to imos.

If “FALSE” selected, the element will be ignored in the imos construction.

read / write

FIELD(name).locked Possible values are “TRUE” and “FALSE”.

If “TRUE” is selected, the input field will be locked.

read / write FIELD(name).image1 You can get or set the path for the image1. read / write FIELD(name).image2 You can get or set the path for the image2. read / write FIELD(name).last You can save the value, previously entered in the field, e.g., for an

“undo” function. read / write

FIELD(name).min ONLY FOR <EDITBOX> elements! This operand sets or changes the minimum value of an EDITBOX text field.

read / write FIELD(name).max ONLY FOR <EDITBOX> elements! This operand sets or changes

the maximum value of an EDITBOX text field.

read / write FIELD(name).info Manipulates the info attribute of an element during runtime write FIELD(name).highlight Highlights the XML element with a color write

FIELD(name).tooltipid Calls a tooltip ID write

(18)

There are some special operands for manipulating the list of items of a selection box in a combo box:

FIELD(name).ItemList(ItemName1,ItemName2,ItemName3, ...) FIELD(name).Info1List(Value1_info1,Value2_info1,Value3_info1, ...) FIELD(name).Info2List(Value1_info2,Value2_info2,Value3_inof2, ...) **FIELD(name).InfoList(Value1_info,Value2_info,Value3_info, ...) –**

* can be any natural number between 1 and n

This is an example for a filter feature. If a certain value is set, only ITEM-elements with matching info=”” names are shown.

The <ITEM> entries that are not part of the list are switched to “invisible” and can no longer be selected by the user.

1.2.5.3 Additional filter-features

In imos NET 6.2.23 and later, it is possible to read and use filter attributes (info1…n) or to manipulate the filter function depending on other field values.

FIELD(name).value=FIELD(Filter_A).info1 FIELD(name).ItemList(FIELD(Filter_B).value) FIELD(name).Info1List(FIELD(Filter_C).value)

It is also possible to run multiple filters one after another to filter the list of items for multiple criteria. So run the commands in a consecutive order.

FIELD(name).info1List(Wert_1)

FIELD(name).filterInfo2List(Wert_2)

(19)

1.2.5.4 Logical Operators

Conditions in IF statements can be nested behind one another. In case you need to define multiple conditions at one level, you can use the following logical operators:

➢ <AND> Conjunction

➢ <OR> Disjunction

➢ <NOT> Negation

In between the tags of a logical operator you can insert one or more conditions. This procedure is analogous to using brackets. There is no limit to the amount of nesting levels.

Example:

<AND >

<EQ expr1=“FIELD(HANDLE_COMBOBOX).value“ expr2=“ITEM(Handle1)“ />

<LT expr1=“FIELD(WIDTH).value“ expr2=“250.00“ />

<OR>

<EQ expr1=“ FIELD(TRUE).value“ expr2=“TRUE“ />

<LTEQ expr1=“FIELD(HEIGHT).value“ expr2=“FIELD(DOOR_HEIGHT).value“ />

</OR>

</AND>

(20)

1.2.5.5 IF statements

All these single contitions can be set up in IF statements. Behind the IF statement, a <THEN>…</THEN> tag follows, where you list the commands to be executed if the condition returns “TRUE”. If you need to catch use cases where the condition returns FALSE, you can use the <ELSE>…</ELSE> tag thereafter. Optionally, it you can add more IF statements inside <THEN></THEN> and <ELSE></ELSE>. This allows to catch all kinds of use cases.

Example:

<IF>

<EQ expr1=“FIELD(HANDLE _COMBOBOX).value“ expr2=“ITEM(Handle1)“ />

<THEN> <!—THEN – node of the 1^st if-statemant -->

<IF>

<LT expr1=“FIELD(WIDTH).value“ expr2=“250.00“ />

<THEN> <!—THEN – node of the 2^nd if-statement --> </THEN>

</IF>

</THEN>

<ELSE>

<!—ELSE – node of the 1^st if-statement -- >

</ELSE>

</IF>

Conclusion: The logic definitions allow you to control the behaviour of the user configuration in the NET shop. The

user interface can be designed more intuitive and you can avoid faulty article configurations by setting limitations.

(21)

1.2.5.6 Commands

Commands allow you to change parameters of specific elements .

<COMMAND> „Sequence of commands“ </COMMAND>

A command sequence consists of only one assignment. For this, any of the operators described above can be used.

Pay attention whether the parameter has a write access.

<COMMAND> „FIELD(HEIGHT_EDITBOX).value = 2000“ </COMMAND>

<COMMAND> „FIELD(HANDLE_SELECTION).visible = FALSE“ </COMMAND>

<COMMAND> „FIELD(HEIGHT_EDITBOX).value = FIELD(HEIGHT_DOOR).max“ </COMMAND>

<COMMAND> „FIELD(LINEAR_DIVISION_SK).value = LIN_DIV($SK1 mm:$SK2 mm:1)“ </COMMAND>

<COMMAND> „FIELD(HEIGHT).value = CALC(FIELD(ZONE1).value+ FIELD(ZONE2).value+150)“ </COMMAND>

<!— Exception !!!! -->

<COMMAND> „FIELD(HANDLE_SELECTION).ItemList(Handle1,Handle2,Beugel1234)“ </COMMAND>

1.2.5.7 Calculations

For calculations with the function CALC you can use FIELD(field_name).value, FIELD(field_name).min and FIELD(field_name).max if valuetype=“NUM“.

Example:

<COMMAND> „FIELD(NUMBER).value = CALC(150+300/2.5)“ </COMMAND>

<COMMAND> „FIELD(HEIGHT).value = CALC(FIELD(ZONE1).value+ FIELD(ZONE2).value+150)“ </COMMAND>

<COMMAND> „FIELD(SQUARE).value = CALC(pow(FIELD(HEIGHT).value, 2)“ </COMMAND>

Functions:

• Power: pow(x

^y

) → x

^y

corresponds to the XML pow(x, y), sqrt(x) → square root of x (= pow(x, 0,5))

• Trigonometric functions: sin(), cos(), tan(), acos(), asin(), atan

• To round: round(), floor(), ceil()

• Others: log() → logarithm of e, exp(x) → e

^x

, max(x1,x2,…,xn), min(…)

Constants: pi = 3,14 ; e = 2.718

(22)

1.2.5.8 Rounding numbers

The rounding function always rounds to an integer (whole number). Use it only in combination with the CALC function.

<COMMAND> „FIELD(NUMBER).value = CALC(round(2.345))“ </COMMAND>

<COMMAND> „FIELD(HEIGHT).value = CALC(round(FIELD(ZONE1).value/3))“ </COMMAND>

To round to a fixed number of decimals, use the following workaround.

<COMMAND> „FIELD(NUMBER).value = CALC(round(12.3333333*100)“ </COMMAND>

<COMMAND> „FIELD(HEIGHT).value = CALC(FIELD(NUMBER).value/100)“ </COMMAND>

<!—The field HEIGHT will display 12.33 -->

If you explicitly want to round up or round down, use CEIL to round up and FLOOR to round down instead.

1.2.5.9 Creating linear divisions

You can create linear divisions using a COMMAND. This linear division can be transferred directly to imos which helps reducing the amount of variables and gives more flexibility.

<EDITBOX name=”SK1” default=”100” ...>

<EDITBOX name=”SK2” default=”200” ...>

<EDITBOX name=”LINEAR_DIVISION_SK”... valuetype=”LINDIV”>

...

<COMMAND> „FIELD(”LINEAR_DIVISION_SK).value = LIN_DIV($SK1 mm:$SK2 mm:1)“ </COMMAND>

The field LINEAR_DIVISION_SK will display the value „100 mm:200 mm:1“; the value will be transferred as such to

imos.

(23)

1.2.5.10 Isolate items inside a Combobox

<COMBOBOX name=“MAT“ label=“Material“ default=“BE“ valuetype=“NUM“ active=„TRUE“ visible= „TRUE“>

<ITEM value=“BE“ label=“Beech“ info1=“WOOD“ info2=“12“ />

<ITEM value=“CH“ label=“Cheery“ info1=“ WOOD “ info2=“15“ />

<ITEM value=“RED“ label=“Melamine red“ info1=“MEL“ info2=“13“ />

<ITEM value=“PB“ label=“Particle board“ info1=“PB“ info2=“13“ />

</COMBOBOX>

…

<COMMAND> „FIELD(MAT).ItemList(BE,CH,PB)“ </COMMAND> <!-- The combobox only shows beech, cherry and particle board →

<COMMAND> „FIELD(MAT).Info1List(WOOD)“ </COMMAND> <!-- The combobox only shows beech and cherry →

<COMMAND> „FIELD(MAT).Info2List(15,13)“ </COMMAND> <!-- The combobox only shows cherry, particle board and melamine red →

1.2.5.11 Composing text

Inside a command, it is possible to compose text snippets. So you can combine fields or free text without a space in between.

<EDITBOX name=”MAT” default=”Beech” ...>

<COMMAND>"FIELD(Basic_Data_Exterior).value='PB19_'+FIELD(MAT).value"</COMMAND>

<!—The value of the field Basic_Data_Exterior is PB19_Beech -->

Free text has to be enclosed in apostrophe ('…’). Link the elements with a plus (+). There is no limit to the combinations.

(24)

1.2.5.12 Messageboxes

A MESSAGEBOX can be helpful to deliver important information to the shop user about the values he entered. For example, if the value will lead to a faulty configuration or if other fields will automatically change their values. These messages are optional and will be displayed similar to internet browser notifications.

Example:

<LIBRARY>

<MESSAGEBOX NAME=" NAME_MSGBOX " LABEL="Demo headline" TEXT="Demo Headline"

TYPE=“MB_OK/MB_OKCANCEL “/>

</LIBRARY>

<COMMAND>“MESSAGEBOX(NAME_MSGBOX)“</COMMAND>

<IF>

<EQ expr1="MESSAGEBOX(NAME_MSGBOX)" expr2="MB_OK/MB_CANCEL " />

</IF> <THEN> … </THEN>

There are two types of message boxes. They differ in the number of buttons and and in their label. The type of message box is defined in the attribute TYPE:

• MB_OK → one OK button

• MB_OKCANCEL → two buttons: „OK“ und „Cancel“

Via IF-statement you can find out which button was clicked by using MB_OK or MB_CANCEL in expr2.

If a message box is used as expr1 of an IF statement, it does not have to be called in a separate command as expr1 will call the box.

Only one <LIBRARY> is allowed in for each article.

The box size of the message box is limited in the imos version iX 2017. So please mind the length of the message.

(25)

Include files

An include file is a subprogram or rather a separate XML file where recurring XML contents can be outsourced so that changes to the code can be quickly applied in a single file – the file can be referenced by any article XML. For example, you have 20 articles that use the same COMBOBOX elements to define the material. To save time and work during setup and maintenance, e.g., when adding/ deleting a material, you should set up an include file where you define the COMBOBOX contents. Link the file in relevant article.xml files and you are done. Changes applied in the include file will automatically affect the 20 article.xml files.

It is irrelevant whether you outsource <DEFINITION> or <LOGIC_DEFINITION> content in an include file, but both types must not be mixed. You can separate them with the element type <PART> so that they can also be called separately. PARTs can be called anywhere in the main program (of course, definitions only inside a definition section;

logic definitions only in the logic definition section).

PART

The element PART is a code segment that is inserted instead of an INSERT call. The names should be unique. Here is an example for an include XML file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<PART name="name_ 1">

</COMBOBOX>

</PART>

<PART name="name_n">

</PART>

</XML>

In the article XML, an include PART is called with the command:

<COMMAND type="INSERT" file="(name of PART-file).xml" part="name of PARTs"/>

Include files can be nested as much as you you want, but do not create “loops”. There is no limit to the amount of

content in a PART. For example, you can include a whole combobox or just their ITEMs. Do make sure the syntax is

correct.

(26)

2. Advanced Functions

FINAL_LOGIC_DEFINITION

(optional – not applicable to IND articles)

In the final logic part, you can define conditions, commands etc. analogous to the normal logic part. The difference is that this part is only executed when the user adds the article to his basket to finish the configuration. The functions and commands available are identical with the standard logic part.

For example, when an IF-condition has evaluated that the user input is not valid, you can add the command

<VALIDATION>0</VALIDATION>

which prevents the article from being added to the basket. The user will remain in the configuration form. If this is the case, you should inform the user about the error via message box.

If the <VALIDATION> command is not executed at all inside the final logic part, the user input will be treated as valid and the article gets added to the basket.

<FINAL_LOGIC_DEFINITION>

<MESSAGEBOX name="MSG_ WIDTH" label="Error" text=" The sum of all widths is greather than the carcass width."

type="MB_OK"/>

</LIBRARY>

<IF>

<THEN>

<COMMAND>"MESSAGEBOX(MSG_WIDTH)"</COMMAND>

<VALIDATION>0</VALIDATION>

</THEN>

</IF>

</FINAL_LOGIC_DEFINITION>

(27)

GLOBAL and GLOBAL CHANGE

GLOBAL.xml

To apply default settings for basic parameters when starting a new configuration, you can create a global XML file.

The structure of the file is identical to an article XML. The values will be transferred onl if the element names match.

The idea is, for example, to set a “global” material so that you can skip setting the starter material in each article.

Link the global.xml in the catalog.xml:

<global file=" GLOBAL" />

….

</category >

</catalog>

GLOBAL_CHANGE.xml

This file is used to change specific properties of all articles of a basket/ room retrospectively. You can also make an article selection to which changes should be applied. The file structure is to an article XML.

Global changes in imos NET 4 shops: Because global changes do not only affect constructive properties but also exchange textures, you must create a texture_mapping.xml. In the file, you define respective textures (read chapter

“Texture_Mapping” for more information). Additionally, a relevant room planner setting must be changed – for this, please contact the imos NET hotline.

To change textures you need the texture_mapping.xml. In this xml are the textures defined, if you select the certain item. (see topic „Texture_Mapping“ in the XML documentation). As well a certain room planner setting must be activated. Please contact the imos NET Hotline for more information.

Link the GLOBAL_CHANGE.xml in the catalog.xml:

<global_change file=" GLOBAL_CHANGE" />

….

</catalog>

(28)

Infobutton – ToolTip

(currently not available in imos iX NET 2019)

You can add info-buttons to XML elements to deliver additional information in the form of text, images or hyperlinks.

To define the tool tip dialogs, a new XML is necessary that is linked in the catalog XML.

Link the tooltip.xml in the catalog

<tooltip file="tooltip"/>

</catalog>

You can use a file name of your choice. But the name must match the one in the catalog.xml link.

ToolTip XML

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

</TOOLTIP>

</TOOLTIP>

</XML>

A ToolTip file contains all tool tips. Each tool tip has a unique name (like an ID) that can be called in the article.xml. If the part TEXT is missing, images will be aligned in the center.

Referencing ToolTips in the article.xml

<ITEM value=”XYZ5” tooltipid=”TT5” label=””…/>

So call a tooltip by its unique name via tooltipid.

(29)

NET Panel module (list input)

imos articles can also be configured via table (list input) instead of a form. In the catalog.xml, add a new section (category_grid).

<category_grid name=“singlepartlist“ show_info=“[TRUE/FALSE]“>

<grid>

<column name="Number" label="lfd.No." column_type="AUTOINCREMENT" view_type="EDITBOX" />

<column name="Article" label="Article" column_type="ARTICLE_LIST" view_type="COMBOBOX" />

<column name="thickness" label="Thickness material" column_type="XML_PARAMETER" view_type="COMBOBOX"

/>

<column name="___CNT" label="Amount" column_type="XML_PARAMETER" view_type="EDITBOX" />

<column name="ART_SIZEX" label="Length" column_type="XML_PARAMETER" view_type="EDITBOX" />

</grid>

<object model="precut1" name="pre-cut 1" />

<object model=" precut1" name="pre-cut 2" />

</ category_grid>

</catalog>

Instead of the typical definition of an object, you insert a category_grid.

In the element <category_grid>, you define the table for the list input. The attribute name of gategory_grid will be shown as a category in the catalog and has to stand alone – not nested in a category. The attribute show_info determines whether a column with an article and info imagea should be inserted to the left of the grid.

In the element <grid>, the table <columns> are listed. The attribute „name“ identifies each column and will be passed on as the variable name to the PVarString. Analogous to the names of EDITBOXES or COMBOBOXES.

The “label” will be the label in a column head.

(30)

Column_type can handle the following values:

➢ AUTOINCREMENT – each cell of this column gets a sequential number which is automatically incremented by 1 in each row.

➢ ARTICLE_LIST – in this column all available articles are displayed (a list of all objects in this category_grid).

If there is only one object, this column is automatically hidden.

➢ XML_PARAMETER – this column is handled like a standard element in the configurator. The values in this column can be manipulated in the logic definition. The view_type determines the form of the column or rather how the column is editable. We distinguish EDITBOX input fields and COMBOBOX selection boxes.

For every model of an object there must be an article.xml of the same name.

NET-Panel inside parafolders

With this module, you can add a NET panel in a specified parafolder of an article configuration. It allows the user to add multiple articles to his cart during configuration, without losing his individual configuration.

<PARAFOLDER type="grid" name="GRID" label="Grid">

<EDITBOX name="AUTOINCREMENT" label="lfd.No." />

</COMBOBOX>

<EDITBOX name="invisible" label="Invisible" default="10" valuetype="NUM" locked="TRUE" visible="FALSE" />

</PARAFOLDER>

The parafolder with the grid/ table output musr be marked with the attribute type=“grid“. Every article can have only

one parafolder of this type. The Editbox name=“AUTOINCREMENT“ fills the column cells with a sequential number

(starting with 1) that is automatically incremented in each row. Display or hide fields inside a row with the attribute

visible=”TRUE”/”FALSE”. The logic of an XML is called for every row and processed independent of other rows.

(31)

Interactive preview

For configurator articles, you can view an article in a live 3D preview instead of the catalog picture (after calling the

article in the browser based shop at the top left). The preview reacts to input in the configuration fields to give the user

a visual feedback. The preview is updated when the user clicks “Refresh 3D preview” or when he switches between

parafolders.

(32)

To use the interactive preview, you need to tweak the following settings:

1. The shop owner can decide, which article should have this interactive preview. In the article.xml file, insert the command <preview interactive="true" />:

<preview interactive="true" />

<ART_NAME>US_1ET</ART_NAME>

<ART_TYPE>ANGOLO</ART_TYPE>

</ARTICLE>

2. Every element like a Combo-, Edit- or Checkbox that has an effect on the geometry (e.g. the dimensions, exchanging connectors, …) needs an additional attribute: geoInfluencing="TRUE". This attribute delivers the information, that the value of this field has an influence on the article geometry. In case the 3D preview is updated, the values will be passed on again.

<EDITBOX name="ART_SIZEZ" label="Height (500 mm - 1000 mm)" active="TRUE" visible="TRUE" image1="" image2="" nosave="FALSE"

locked="FALSE" valuetype="NUM" default="768" min="500" max="1000" geoInfluencing="TRUE" />

3. Only for imos NET shops: The textures displayed in the 3D preview will passed on to the construction parts.

That means: if there is a material combobox where a material item is selected, the system assigns a JPG to the parts. To make it work, it is necessary to link a texture (JPG) with the affected variable (please have a look at the topic “Texture_mapping”). This file is uploaded in the directory imosnet/vg_2xxx/vrml/textur.

In the Configurator of imos iX 2017, there is no texture_mapping file necessary, because all textures are already

stored locally on the device and all information will be read out of the imos database. The attribute

geoInfluencing=”TRUE” is still mandatory.

(33)

System variables

Some variables that are already defined in the imos system can optionally be used. Listing them in the part

<CONSTRUCTION> is not required. Just use the variable name as name=”” in a combo- pr editbox.

variables valid version description

___CNT Configurator

and imos NET

Sets the article count in the basket. Should not be used in combination with the room plan.

___CalcPrinciple imos NET Defines which calculation principle is used for price calculation.

___ARTICLE_POS_Z imos NET Defines the insertion height of the article in the room plan.

___NOTES imos NET The text will be transferred to the article notes in basket list

___PREVIEW_ENABLED

Imos NET To blend out (invisible) the 3D icon. →

default="0"

(34)

Localization of XML

Since NET 4.0, XML files can be translated server-side into the user language. The translation for each string is defined in XLIFF format and must be linked in the corresponding XML file with the call: <translate file="2000_1.xlf"/>.

<translate file="2000_1.xlf" />

<ARTICLE>…

This call must be inserted in the catalog.xml and article.xml files. But do skip the call in include files, because the article.xml already references it. Upload the file to fileadmin/imosnet/2xxx/ll/ .

There must be a XLIFF file for each target language; you must stick to the file name pattern [language key].[name of file].xlf .

Example: de.2000_1.xlf

The file name is up to you. Only the language key is predefined. Please contact the imos hotline for more information.

For translating an individual String, there is a placeholder {translate:key|default} that can be used in any attribute (except for “unique” ones like name=”xyz”). If there is no default key {translate:key} and no translation, „[key]“ is output.

It is also possible to manipulate the logic definition (the label or text of message boxes).

Example:

<ART_INFO_SHORT>{translate:SRT_INFO_SHORT}</ART_INFO_SHORT>

(35)

**Structure of *.xlf**

<?xml version='1.0' encoding='utf-8'?>

<body>

<trans-unit id="para1">

<source>Parafolder 1 xliff source</source>

<target state="approved">Parafolder 1 xliff target</target>

</trans-unit>

<trans-unit id="msgbox.title">

<source>Messagebox title</source>

<target state="approved">title of message </target>

</trans-unit>

<trans-unit id="msgbox.text">

<source>Messagebox text</source>

<target state="approved">Text of message\nöäß</target>

</trans-unit>

</body>

</file>

</xliff>

Relevant for the output, is the text in the tag „target“. The attribute “target-language” must match the prefix in the

filename!

(36)

Texture_mapping.xml

The texture mapping of the interactive preview is implemented with an additional XML file. Texture mapping only affects the visualization.

Only those textures can be referenced, for which a variable is allocated in a part on the levels Material, Profile, Surface or Color Principle in imos. The mapping is based on the article configuration. Presets defined in imos CAD are ignored.

The texture mapping via XML file can be used to assign a texture to articles within the room planner (up tp NET 4.0) or in the interactive preview depending on the article configurator settings. The texture_mapping.XML only influences the visualization.

Imortant notes

1. When mapping via texture_mapping.xml, the file must contain a definition/ description for each possible variation, because the conventional texturing will no longer be active.

2. Mind that the JPG files must have a resolution of 2^n, for example: 256 by 512 pixel. The aspect ratio is irrelevant – it can be square, landscape or portrait.

3. You can add transparency to a material with the attribute:

<VALUE NAV_VALUE="02_oream.jpg" IMOS_VALUE="MASIV_ORECH_KLASIK" transparence="0" />

The level of transparency is set by the attribute’s value. Valid values go from 0 to 1.

(example: 0/0.2/0.4/0.6/0.8/1)

(37)

Structure of the XML Procedure:

In the shop, there often is a material selection implemented as an edit- or combo-box. The logic in the texture_mapping refers this selection.

Example:

When I select the ITEM „FPY19_MEL_Be“ in the combo-box „basic_data_box“, I want to apply the texture

„i_Beech.jpg“ on the material variable „MAT_BOX_EXT_1“. Like this, the textures are assigned to a variable.

If a Surface variable is applied in a Part Definition, it must be called in the XML.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<VARIABLES_MAPPING>

<VARIABLE nav_name="Variable Name" imos_name="Fieldname of Article.xml">

<VALUE imos_value="Value of field (ITEM Name)" nav_value="Filename of texture" />

</VARIABLE>

<VARIABLE nav_name="MAT_BOX_EXT_1" imos_name="basic_data_box">

<VALUE imos_value="PB19_MEL_MA" nav_value="i_MAPLE.jpg" />

<VALUE imos_value="PB19_MEL_Be" nav_value="i_Beech.jpg" />

<COMMAND type="INSERT" file="INC_texture_mapping.xml" part="BOX"/>

</VARIABLE>

<VARIABLES_MAPPING>

<VARIABLE>...</VARIABLE>: TAG where the mapping for a variable is defined.

nav_name: Name of the imos variable to be modified.

imos_name: Name of the XML element in the Article.XML which provides the value for the change.

<VALUE>...</VALUE>: TAG where a texture is assigned to a value of the selection field/ variable.

imos_value: ITEM (Name) of the XML field defined before (imos_Name).

nav_value: File name of the texture that is to be used

(38)

Dependencies Article.XML:

<COMBOBOX name="Materials_Case" >

<ITEM value="FPY19_MEL_AH" />

<ITEM value="FPY19_MEL_BI" />

</COMBOBOX>

imos variables

Textures

2 .

1 .

4 . 3

.

(39)

The XML can consist of any amount of VARIABLE blocks following this pattern: One block always defines the assignment of one texture file to one imos variable.

<VARIABLE nav_name="MAT_1" imos_name="Materials_Case">

nav_name refers the name of the imos variable used (1.). imos_name refers the name of the field (2.) within the Article.XML that influences the visualization of the material in the room plan.

Within a VARIABLE block, any amount of VALUEs can be defined:

<VALUE imos_value=" FPY19_MEL_AH " nav_value="i_MAPLE.jpg" />

A VALUE tag always defines the mapping (assigment) of one texture to one value. The attribute imos_value represents the reference to the value (name of ITEM) (3.) of the field within the XML. The attribute nav_value defines the file name (4.) of the texture to be used.

In general, the same texture is assigned as the one assigned in the material used. (4.) = (5.)

Note:

When writing the VARIABLE blocks, the sequence of the described elements is relevant for the texture that is finally mapped.

So a variable priorly controlled by a value set – which has to be controlled directly via texture mapping now – can be

overwritten retroactively by an XML field within the Article.XML and vice versa.

(40)

Vartext.xlf

The vartext.xlf serves the translation of variables and their values as well as the translation of article names for the article description in the cart and in the offer. In accordance, the variables will be output that have been determined in the vartext.xlf. Values for the variable do not necessarily need to be translated. In that case, the value in the PVarString will be output.

Target language

It is important that Vartext.xlf files are named after the following schema:

LanguageInitials.vartext.xlf Example:

DE.vartext.xlf EN.vartext.xlf Language settings

The entry in the “index” defines what language the translation belongs to. This entry is only used for multilingual users, otherwise the index is always "default". In case multiply languages are activated, “default” has to be used as the Englisch translation.

Translation of variables and values

<label index="NAME_VARIABLE">Output in cart: %s mm</label>

In the attribute "index", you define the variable to be translated. The output is entered between the start and end tag.

%s is the placeholder for the value of the variable .

<label index="NAME_VARIABLE.VALUE_VARIABLE">Translation of the value</label>

To translate a variable value, use the same notation for the index attribute as shown above. The translation of the

value is assigned to the translation of the corresponding variable instead of %s. It is possible to filter certain variables

or values of a variable of an article. In that case, both the variable and the value will no longer be shown in the

shopping cart or in the offer. For filtering, you have to use DO_NOT_DISPLAY as translation for the value. Only the

(41)

<label index="NAME_VARIABLE.NO_DECOR">DO_NOT_DISPLAY</label>

<label index="ARTIKEL_XYZ.NAME_VARIABLE ">DO_NOT_DISPLAY</label>

If different variables have (partially) identical values and identical value translations, we advise you to set up a default translation for such values: simply call the variable name DEFAULT:

<label index="DEFAULT.FPY19_BE">beech veneer</label>

The default translation will always be used if there is no other translation for an explicit variable (name).

Translation of the article name

<label index="NAME_ARTICLE">Output in the cart and in the offer</label>

In the attribute "index", specify the article to be translated. Enter the output text between the start and end tag. If an article is not translated in the vartext.xml, ART_NAME (namei in the article XML) is output.

Article specific output of a value

In case, a variable name or a value of a specific article should be output different from other articles, you can do so by linking the article name, variable and value.

Example:

Usually, ART_SIZEX should be the “article width”

<label index="ART_SIZEX">Width: %s mm</label>

For a Worktop (article name WORKTOP), we want ART_SIZEX to be displayed as “Length” instead. It is also possible to define more than one use case.

<label index="WORKTOP.ART_SIZEX">Lentgh: %s mm</label>

<label index="WORKTOP2.ART_SIZEX">Lentgh in mm: %s</label>

You can also define article specific values:

<label index="ARTIKEL_NAME.NAME_VARIABLE.WERT_VARIABLE">Translation for a variable value of this article</label>

Formatting of the article description

The output can be formatted by "pseudo-HTML". There are currently four options available.

[b] … [/b] → the text will be formatted to bold

[u] … [/u] → the text will be formatted to underlined

(42)

[i] … [/i] → the text will be formatted to italic [br] → inserts a line break

Another option is to set all "labels" to bold autmoatically, like "Height" in the example below, without explicitly defining it in the vartext.xml. This setting must be done once on the part of imos.

Example:

<label index="ART_SIZEZ">[b]Height:[/b] [i]%s[/i] [u]mm[/u][br]</label> → Height: 100 mm