code conventions

Code conventions are important to produce a homogeneous code.
Many reasons:

Software maintenance is easier (software is rarely maintained by the original author)
Code conventions improve the readability of the software

This chapter present the MeMo application coding standards.

Indentation:
Use 2 spaces for a tabulation.

In VRML, Nodes should have the following form:

Node {
  attribute1 0
  attribute2 [
    "toto"
    "titi"
    "tata"
    "tutu"
  ]
  attribute3 [0 0.5 1]
}

In Javascript, a if-else class of statements should have the following form:

if (condition) {
  statements;
}

if (condition) {
  statements;
} else {
  statements;
}

if (condition) {
  statements;
} else if (condition) {
  statements;
} else {
  statements;
}

In Javascript, a switch statement should have the following form:

switch (aVariable) {
case const1:
  statements;
  /* falls through */

case const2:
  statements;
  break;

case const3:
  statements;
  break;

default:
  statements;
  break;
}

When you name a node with keyword "DEF" the name of the node should be all uppercase with words separated by underscores.
It should also contain the function of the node (prefix) and the type of the node (suffix).
Example :

Shape {
  appearance Appearance {
    material DEF BG_MAT Material2D {
      emissiveColor 0 0 0
    }
  }
}

In VRML, when defining a node with a "DEF" keyword, you should use the following suffixes depending on the type of node:

Nodes	Suffix
Appearance	_APP
FontStyle	_FS
ImageTexture, MovieTexture	_TEX
Layer2D	_L2D
Material, Material2D	_MAT
PositionInterpolator	_PI
Rectangle	_REC
Text	_TXT
TimerSensor	_TIMER
Transform, Transform2D	_TRS

Example:

Shape {
  appearance Apperance { material DEF LABEL_MAT Material2D { [...] } }
  geometry DEF LABEL_TXT Text { [...] }
}

Javascript fields should use the Java notation for variables, that mean :

Field names and variables in Javascript should have a lower case first letter.
Internal words start with capital letters.
Variable names should not contain underscore _ or dollar sign $ characters.
Variable names should be short yet meaningful.
The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use.
One-character variable names should be avoided except for temporary "throw away" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.

Example:

Script {
  field SFNode bgMat USE BG_MAT
  field SFInt32 myInteger 0
  url"javascript:
    function initialize(){
      var w = Browser.getWidth();
      myInteger = w;
    }
  "
}

When the developer specializes a Prototype in another Prototype (for example : Alert.wrl specialize Slider.wrl), the CSS file should look like the following:

Alert {} // CSS Node for Alert prototype
Alert-title {} // Subset of Alert prototype
Alert-message {} // Another subset of Alert prototype
Alert-Slider {} // customization of Slider prototype by Alert prototype

The CSS Node for Alert should show that it specializes the Slider prototype : Node Name = "Alert-Slider" and have the same elements that the Slider CSS Node.
The difference is made between Specialization (named : "Node-Spe", with first letter of specialization in upper case) and Subsets (named "Node-subset", with first letter in lower case).

This pages contains conventions that should be followed when writing VRML prototypes with MemoSDK.

Naming

Use convention for java classes naming (first letter upper case of word, following lower case).
Example: ScrollableText, Menu, ProgressBarMenu

Parameters

Every prototype should have the following parameters :

field SFVec2f screenSize : to handle changes in screen size
field SFString style : to handle custom CSS styles

Inner nodes

Inner script(s)

Screen size handling

Prototype should support screen resizing via the screenSize field.
Example of support of screen resizing:

PROTO myScene [
  field SFVec2f screenSize 0 0
] {
  Title {
    screenSize IS screenSize #Spread screenSize to Title prototype
    title ["Title of scene"]
  }
  Script {
    field SFVec2f screenSize IS screenSize #Use of screenSize in script for calculation
    url "javascript:
      function screenSize() { //position icon at top-middle of the screen
        icon.translation.y = (screenSize.y/2) – (iconSize.y/2);
      }
    "
  }
}

Style handling (not available for tiny widgets)

Prototype should support style modification via the style field.
See Style for Javascript API and CSS language for the CSS file syntax.
Example:

PROTO myScene [
  field MFString style ["myScene"]
] {
  Title {
    style IS style #Spread style to Title proto
    title ["Title of scene"]
  }
  Shape {
    appearance Appearance {
      material DEF BG_MAT Material2D { emissiveColor 0 0 0 } #background color
      texture DEF BG_TEX ImageTexture { url ["" "image.png"]} #background texture (for images)
    }
    geometry DEF BG_REC Rectangle { } #background rectangle
  }
  Script {
    field MFString style IS style #Use of style in script for customizing
    field SFNoce bgRec USE BG_REC
    field SFNoce bgMat USE BG_MAT
    field SFNoce bgTex USE BG_TEX
    url "javascript:
      function initialize() {
        Style.getCoord(style, 'size', bgRec.size, screenSize.x, screenSize.y); //set size of background depending on the style
        //a light mode exists for Mobile Widgets low end devices, check if it is activated or not
        if (Style.getBool('Common', 'light') == false) { //standard mode : load a background image
          bgTex.url[0] = 'image.png';
        }
        else { //light mode : don't load image, just a background color
          Style.getColor (style, 'color', bgMat.emissiveColor); //set background color depending on the style
        }
      }
    "
  }
}