# Roomle Content Naming Conventions

# Patterns for Naming Parameters and Variables in Given Situations

Situation Prefix Example Typical type and values
Can change element type to canBe- canBeFootstool Boolean
Can change to a situation can(Be)- canBeFreestanding Boolean
Can have accessory or neighbour of type docked canHave- canHaveFootstool Boolean
Has accessory or neighbour of type docked has- hasFootstool, hasLegs Boolean
Has child behind a dock mask has<Mask>Child hasLeftChild, hasTopChild Boolean
Has accessory of type <accessory>Type legsType, handleType String / matching with that accessory's parameter
The main type of this component elementType elementType String
Is child behind parent's mask is<Parent's Mask>Child isLeftChild, isTopChild Boolean
Is in a situation is- isFreestanding, isOnFloor, isRoot, isCorner Boolean
Is of type is- isFootstool Boolean
Situation of a [neighbour/child] behind a connection mask <mask> -[Neighbour/Child/][Is/Has/CanBe] leftNeighbourElementType, topChildHasBottomShelf, rightNeighbourIsCorner depends on the situation
Docking mask should be allowed <=> can dock with that mask allow- <mask> -Dock allowLeftDock Boolean
Count of accessories docked count- (-docked) countFootstools(Docked), countPillows Integer
Main component's material material material Material
Distinguish between main component's materials if we can't say one of them is the main <part>Material countertopMaterial, sidesMaterial, frontsMaterial Material
Material of some accessory <accessory>Material legsMaterial, handleMaterial Material
Dimensions of components that go in volume width, depth, height, diameter, radius width, depth, height, diameter, radius Decimal (!)
Position of docking points or accessories <situation>Pos[X/Y/Z] leftDockPosX, topDockPosZ Decimal (!)
Base dimensions for accessories or dock placement <situation>[Width/Depth/Height/Length] legsBaseWidth, dockDepth Decimal (!)
Sizes of construction elements <part>[Width/Depth/Height/Length/Thickness] woodThickness, Decimal (!)
Gaps or distance between, offset of first <situation>[Gap\Offset] freestandingDockGap, holesOffset, holesDistance Decimal (!)

Always use camelCase to separate words in variable and parameter names instead of using underlines_to_separate_words. If the identifier has an abbreviation, let only the first character of the abbreviation be uppercase, like weHaveAbcAbbreviation or abcAbbreviation instead of weHaveABCAbbreviation or aBCAbbreviation.

# Naming Components

Since the componentId alredy has the catalogueId, it is clearly distinguishable to which project it belongs. A delimiter _ follows. Last part of the componentId should denote what the actual thing is. All componentIds are lower case. The format should then be:

catalogueid:projectname_partname

The reason is that this is much easier to remember as for example having to remember Celeste_FootStool or Celeste_Footstool.

Examples:

We have a Celeste sofa system by ABC-Design:

abcdesign:celeste_master - the master component for following subcomponents

abcdesign:celeste_1seater

abcdesign:celeste_corner

abcdesign:celeste_longchair

If there are more articles in one component, use plural.

abcdesign:celeste_pillows

# Naming items

ItemIds should carry information on to which componentId they lead to. It does not have to be equal, but the content creator should understand this from reading the itemId already. Pattern for selecting itemId:

catalogueId:projectname_partname_[distinctiveParameterValue]

Examples:

abcdesign:celeste_longchair_left, abcdesign:celeste_longchair_right (longchair_left and longchair_right are elementType values, we omit "master" in itemId)

abcdesign:celeste_1seater_1200 - single seater of width 1200 (you expect that this is width in sofa elements)

shelfmasters:supershelf_frame_800_400 leads to a frame of size 800x400 (probably width x height) -> If there are more dimensions in the itemId, follow the natural width x depth x height order

# Language Specific Characters for Identifiers

Use english equivalents for the identifiers and componentIds. If, for any reason, you need to write them in any different language, handle the language specific characters in a way that is common to that given language, for example:

  • German
    • ä, ö, ü -> replace with ae, oe, ue
    • ß -> replace with ss
  • Czech
    • ignore diacritic marks ě, š, ž, ý, á, ů -> e, s, z, y, a, u etc.

This is of course not relevant for labels or string content, where you should display the texts correctly.

# Naming docking masks

The docking masks should contain information about what can be docked behind it. Imagine it as a connector, where you specify the standard you need for the other part to connect. There can be several situations:

  • you dock a part of a modular product (sofa, shelf frame) - use the same prefix of the product as you use for the componentId
  • you can dock one concrete part - use a docking mask describing the part
  • you can dock a type of accessories - use an umbrella term of matching accessories

Use the masks as they are described above in cases, where there is only one child docking point on the child side - that means that the child has only one connector and the position of the docking does not influence the child further. However, if you need to distinguish this (generally if the child is not smaller than parent or is not lower in the product hierarchy), use one of words like: left, right, bottom, top, back, forward etc. from the perspective of the parent. Example: sofamoduleLeft, where the parent docking point is on the left in the parent component and on the right in the child component. Be aware that this takes some time to get used to this when you work in the child's perspective.