Color-chooser, part II. Three pieces of the Puzzle.

Functionality of our color-chooser requires some code to be designed as we definitely need to handle UI events and do some initialization of our component.

Typical OOP solution for that is to design such code in a form of some class. Then we need some mechanism that will allow us to "bind" such class with the DOM element we have defined in HTML as:

< input type="color-chooser" />

In other words we need to define (or declare) our own behavior for some class of DOM elements.
In Sciter we can do this as a simple definition like this (script):

type ColorChooser : Behavior { /* declaration of behavior class object */

  function attached() 
  {  
    /* initialization code 
        'this' here is the DOM element the behavior attached to. */ 
  }
  function onMouse(evt) 
  { 
    /* event handling code
       'this' here is the DOM element the behavior attached to. */
  }
}

At this stage we have behavior class defined and DOM element we want this behavior to be assigned to.

Sciter allows us to bind these two entitites declaratively by using CSS and special prototype attribute. Here is an example of such definition – all DOM elements satisfying given CSS selector will have following attributes:

/* all input elements having type attribute equals color-chooser */
input[type="color-chooser"] 
{
    background: .... ; /* and other rendering styles */
    prototype: ColorChooser /* behavioral style definition */
}

Done. If we will put together all these three pieces of the puzzle we will have our <input type="color-chooser"> look and behave as a color chooser control. In fact all other input elements in Sciter are simply DOM elements that have specific styles and behaviors assigned.

In the next article I will explain what really happens "under the hood" – how existing element is getting "subclassed".