Q.tis – micro port of jQuery for Sciter.

I’ve published today Sciter 2.0.2.2 with q.tis – micro-port of essential jQuery features.
Here is the list of supported functions.

It is just enough to put include "t.tis"; in your code and any existing DOM function that returns array of elements will
“automagically” produce the q-collection.

In my implementation I am using the fact that functions like Element.selectAll("selector") return array object that is instanceof ElementList.
ElementList as any class is extensible in run-time. So I’ve just added bunch of function ElementList.jqueryMethod() {} to bring that functionality to the Sciter.

The beauty of the approach is that you can use as the q() function (analog of $() in jQuery) as Sciter’s standard $$() to write something like this:

var itemsWithLinks = $$(ul.topics > li).$has(a:link);

to get list of list items that have <a>’s inside.
The same but in classic style and without use of “stringizers”:

var itemsWithLinks = q("ul.topics > li").has("a:link");

You may also find handy jquery-alike event handling. Methods element.on(), element.off(), element.one() and element.trigger() are available as for q-collections as for DOM element instances.

Sciter 2.0.2.0 is out with new TIScript features

One of such features added in 2.0.2.0 is support of member variables declarations in classes.

By using this var name = value construction you can define member (instance) variables:

This code:

class Foo {
  this var one = 1, // member variable
           two = 2; // member variable

  function sum() { return this.one + this.two; }
}

var foo = new Foo();
stdout << foo.sum() << "\n";

will output ‘3’ even there is no constructor is defined in the class.
Each instance of the class is born with those this.one and this.two variables having their initial values.

If there is other class that inherits such Foo class then it gets member variables declared in its super class as the ones declared in the class iself.

This code:

class Bar: Foo {
  this var three = 3; // member variable

  function sum() { return this.three + super.sum(); }
}

var bar = new Bar();
stdout << bar.sum() << "\n";

will ouput ‘6’ as the bar instance contains this.one, this.two and this.three variables.

Making TIScript syntax compatible with CSS.

Time to time when I need to define some CSS constructs in script I feel myself non-comfortable – CSS and JavaScript/TIScript use different syntax’es.

Consider this code in JavaScript:

  function switchState() 
  {
    element.style.backgroundColor = "rgb(126,0,0)";
    element.style.transform = "rotate(45deg) translate(10px,10px)";
  }

Not so aesthetically pleasing. And not so effective as string parsing is involved.

And yet if for example you will need to get current rotation angle from style, increment it by some value and write it back then you will need to implement non trivial parsing using CSS rules and opposite toString translation for changed rule.

I’ve explored quite many JS frameworks that are capable working with styles – all they have good chunk of parsing CSS code.

But browser already parses the CSS and builds internal structures that represent CSS values. Code is there, why not to reuse it?

One way of dealing with this is to expose CSS internal structures using so called CSSOM. But that’s really too much work and result is still too narrative I would say.

Ideally that should look like this:

  function switchState() 
  {
    element.style.set {
      background-color: rgb(126,0,0),
      transform: rotate(45deg) translate(10px,10px) 
    }
  }

And in principle JS syntax can be extended to support such constructions without conflicts with existing code:

  1. Allow names with hyphens like background-color in object literals.
  2. Allow values with units like 45deg, 10px and the like. That will require new data types in JS but they are handy anyway
  3. Add so called tagged tuples to the language. In terms of CSS this rotate(45deg) is not a function call but rather tuple (data structure with the name). In terms of TIScript this can be written as [rotate:45deg] – one element tuple with the tag ‘rotate’.
  4. Add whitespace as a valid list separator, at least in object literals, so this
       { transform: rotate(45deg) translate(10px,10px) }
    

    will be an equivalent of

       { transform:[rotate(45deg), translate(10px,10px)] }
    

    And that would be pretty much it.

In fact CSS syntax (that may look like a mess sometimes) uses in reality two types of lists and one tuple<2> (in order of precedence):

  1. comma separated lists: background: url(1.png),url(2.png);
  2. white-space separated lists: background: no-repeat url(1.png);
  3. pair-tuples: font: 12pt 10pt/14pt "arial";

But that would be next step. At the moment I am trying to add values with units and whitespace lists…

Use of CSS constants in script.

In Sciter you can define CSS constants using @const declarations like this:

<style>
  @const TEST_STR:"test";
  @const TEST_COLOR: rgb(128,0,0);
  @const TEST_NUMBER: 128;
</style>

and use them not only in CSS ( as @TEST_COLOR for example ) but also in script using accessor like this:

var test_str = self.style.constant("TEST_STR");

If you think that self.style.constant is too narrative then you can define short “stringizer” function for it:

  function $const( name ) { return self.style.constant(name) || ""; }

and later use it as:

var t1 = $const(TEST_STR); // "test" string
var t2 = $const(TEST_COLOR); // object of type Color, color(128,0,0)
var t3 = $const(TEST_NUMBER); // integer, 128

What does “::” construction mean in TIScript?

Got this question in one of emails…

One of forms to declare anonymous function in TIScript is so called single statement lambda function:

':' [param-list] ':' <statement>;

Let’s say we have this JavaScript code:

var counter = 0;
var inc = function() { counter++; }

So each time when you call inc() the counter will be incremented.

By using TIScript’s lightweight syntax we can do exactly the same by declaring:

var counter = 0;
var inc = :: counter++; 

So first “:” here is exactly “function(” and second “:” is “)” in JS declaration.

You of course can use standard JS way of declaring functions in TIScript too, I just think that sometimes shorter forms are better. Like here:

var accounts = [...]; // list of accounts
accounts.sort( :a,b: a.balance - b.balance );

Instead of quite noisy:

accounts.sort( function(a,b){ return a.balance - b.balance });

Ruby has similar lightweight approach of declaring similar entity:

[1,2,3,4,5].each {|i| print "#{i} "}

That in JS will be

[1,2,3,4,5].each(function(i){ println("#",i);});

JavaScript vs Dart/Chrome vs TIScript/Sciter

Here is a comparison table of JavaScript/jQuery, Dart/GoogleChrome and TIScript/Sciter:
www.terrainformatica.com/sciter/js-dart-tis.htm.

It tries to compare similar features among these three technologies.

My TIScript looks pretty good if you would ask me. Not that extreme as Dart and
close to original JavaScript while bringing needed modularity and convenience.

The document is based on synonym.dartlang.org , if someone think that there is a copyright violation – please let me know.

Just for the note: another TIScript vs JavaScript comparison is here.

Closures, view from implementation perspective.

There are plenty of definitions of ‘closure’ term on the web. Most of them quite generic and here is my attempt to define what is the closure under the hood. Hope it will help to someone to understand better the subject.

Technically speaking closure is a data structure that combines reference to function body and non-empty list of call frames active at the moment of declaration.

Closure is created by executing some code that contains declaration of a function that uses variables from outer scopes. In this case VM (virtual machine), while executing the code, has to create not just reference to the function but closure structure – function reference and reference to its current environment[s] – list of call frames that hold used outer variables.

Here is JavaScript example of function that returns closure:

function Foo() {
   var zoo = 2;
   function Bar(p) {  
     return zoo + 2; // using 'zoo' variable from outer scope.
   }
   return Bar; // returning inner function reference
}
var bar = Foo(); // here 'bar' contains Bar instance (the closure).
...
alert( bar() );  // invoking the function-closure.

In order Bar function to work it should have reference to outer call frame (the one that contained ‘zoo’ variable).

And here is an example of plain function declaration – function referred by bar uses only its own variables:

var baz = function() {
   var zoo = 2;
   return zoo + 2; // using 'zoo' variable from its own scope.
}

To represent JavaScript closure and plain function we can use following definitions (C++):

  struct Function { // plain JS function
    bytes bytecode; // executable code of the function.
  };
  struct Closure {  // JS closure
    bytes bytecode;        // executable code of the function.
    cframe* cframe_chain;  // callframe chain, used to get/set variables in outer call frames.
  };

If we don’t care too much about memory consumption then we can declare JS function as a generic class that will cover functions and closures in single entity:

  struct Function {  
    bytes bytecode;      // executable code of the function.
    cframe* cframe_chain_nullable; // callframe chain, is NULL for plain functions.
  };

For any given JS function compiler can determine is it using outer variables or not. So it can tell if closure creation is required for given function declaration. It makes sense to do such detection as creation of closure is pretty expensive – VM shall move call frames from stack to the heap – convert callframes to GCable objects. If closure is not required by the nature of particular function VM should not create the closure and so heap will not be polluted by unused call frames.

The KiTE – template engine for JavaScript


Preface

Modern Web applications frequently use AJAX kind of client/server interaction. They receive data from the server in pure JSON format. That means instead of generating markup on the server such applications are composing HTML inside the browser (on client side).

Straightforward approach is to use string concatenation spagetti like : "<b>" + data + "</b>".  But this almost always will end up in non-maintainable mess. Real Jedi use markup templates. Typical PHP page is a script with embedded HTML – typical template the gets "instantiated" for the particular GET request/data/user.

PHP or plain old ASP are not only possible template formats. There are a lot of template engines and template languages in the wild. All of them fall into four major groups:

  1. Minimalistic, logic-less: {{mustache}} and (probably) PURE;
  2. Still simple TDLs but with some simple logic like if/else construcs: jQuery.tmpl() and the KiTE,
  3. PHP or ASP alike templates: JavaScript constructs embedded in HTML using <% %> brackets: jQote, John Resig’s Micro Templates, EJS, etc.
  4. Group of template engines based on #haml/Ruby ideas – they use special non-HTML markup.

In general: as simple language, less syntax noise it creates – as better. Easier to comprehend and so easier to maintain. The worst case from this perspective is actually PHP (group #3) – mix of two different syntaxes in single source (script and markup) can easily become not readable.  

Speed of template instantiation is on other axis of "templates space". Implementation of PHP alike templating (group #3) is relatively straightforward with JavaScript. Basic idea is to replace all text between
"%> ... some markup... <%"  
by something like
 out += "... some markup...";  
and wrap the template into
 compiled = new Function(transformed_template).

Template instantiation in this case is a matter of calling such function. This approach potentially is as fast as JavaScript itself. But as I said the template source is too "dirty" even in simple cases. I believe that code from this article http://blog.futtta.be/2011/01/18/how-to-do-jquery-templates-with-jqote2/ is a good example of how messy it can be with just few if/else’s.

On other side {{mustache}} templates are pretty clean but current {{mustache}} implementation is extremely slow. According to jsperf.com/dom-vs-innerhtml-based-templating/96 it is 150 times slower than the most effective jQote2. Too bad to be honest.

Another problem with the {{mustache}} is its logic-less nature. I understand the motivation but in reality some simple logic is required. Something like "if fieldA > 10 then render the record one way otherwise in some other".

So I came up with …

The KiTE.

KiTE is lightweight (180 lines of code) and fast JavaScript template engine. It uses template defintion language (TDL) that is close to {{mustache}} but with few additions: conditional sections and custom formatting functions.

Here is an example of KiTE template that emits simple list of contacts:

<ul>
  {{#contacts}}
    <li><b>{{firstName}}</b> <i>{{lastName}}</i></li>
  {{/contacts}}
</ul>

When given by JS data in following format:

{ contacts:
  [ { firstName: "Ernest", lastName:"Hemingway" },
    { firstName: "Scott", lastName:"Fitzgerald" } ]
}

the template will be instantiated as this list:

  • Ernest Hemingway
  • Scott Fitzgerald

KiTE templates can be placed in

<script type="text/x-kite">
  ...
</script>

sections on the page so they will not polute JavaScript code.

You can use this document http://terrainformatica.com/kite/test-kite.htm to get a feeling of the KiTE templates.

Idea behind KiTE implementation, defintion of TDL and the kite() function are all explained here code.google.com/p/kite/

And the last: the name "KiTE" is an acronym of "KiTE is a Template Engine".

Behaviors, simple jQuery extension.

Behaviors as an entity is a declarative way to assign/bind scripting methods to DOM elements.

We can think that browsers have following declarations in their default CSS declarations:

input[type=text]   { binding: TextEditorImpl; }
input[type=button] { binding: ButtonImpl; }
select             { binding: SelectImpl; }
...

So when we define <input type="text" /> in our markup we declare that the element will behave as a text editor – it will have set of all needed methods and will generate all associated events.  

It would be nice if in script we would be able to define our own behaviors for classes of DOM elements too.

As an example: blog article may have hyperlinks inside and particular blog engine may require some special behavior/reaction assigned to all hyperlinks in the article. Ideally such declaration should like this:

#content div.article a[href][title] 
{
  color: orange; // ui style
  behavior: LinkWithSmartTooltip; // behavioral style
}

In Sciter [1] that is an embeddable HTML/CSS/TIScript engine I have a luxury to step beyond W3C specifications so I’ve implemented the Behaviors in the way as I think they should be:

Behaviors in the Sciter engine

I have added the prototype attribute to my implementation of CSS:

some-CSS-selector 
{
   prototype: SomeBehaviorClass [ url(of a script file) ];
   ...
}

When the engine assignes CSS styles to elements it also tries to find class named SomeBehaviorClass. If such class is found then the element gets "subclassed" by the class. Technically the subclassing means that for all DOM elements that satisfy some-CSS-selector both these statements are true:

element instanceof SomeBehaviorClass; 
element instanceof Element; // Element is a super class of all DOM elements.

The SomeBehaviorClass looks in TIScript like this:

class SomeBehaviorClass: Behavior
{
   function attached() {} // constructor, sort of
   ...
}

The attached method plays a role of a constructor function in realm of Behaviors. It is called when particular element gets the behavior with this variable referring to the element. All this is I would say is pretty human readable an transparent.

Ok, back to the reality of the Web. Below is my attempt to define similar functionality using jQuery:

Behaviors for conventional browsers,  jQuery extension.

First of all here is my initial implementation of the behavior functionality: jquery-behaviors.js. It is pretty simple – near 75 lines of code.

It allows to declare behaviors on elements by using (a) class DOM attribute like this (purely in markup):

<span class="behavior uix-slider" /> 
<input class="behavior uix-date" />

and/or by (b) declaration of selector rules in script code:

$.behaviors.selector("ul.ext-list > li", MyExtListItem );

Later case allows to add behaviors non-intrusively – to any existing markup.

The Behaviors implementation above introduces three methods:

  1. $.behaviors.add( name, behaviorObj ) – add named behavior that can be used in "a" case above – in class names.
  2. $.behaviors.selector( selectorStr, behaviorObj ) – add "CSS selector -> behavior" association – case (b) above.
  3. $.fn.behaviors() – that is a plug-in that extends jQuery object wrapping set of elements. It used after calls of DOM mutating methods to assign behaviors to DOM elements:
    $("#update-panel").html("....").behaviors();

The behaviorObj above is the behavior implementation per se. It is a plain JavaScript object that defines set of methods and properties that will be mixed into the DOM element property map.

Here is a typical structure of some behavior named "x-checkbox" (see it’s demo here …) :

$.behaviors.add( "x-checkbox", 
{
  $attached: function(params) { ... },
  $value: function(v) { ... },
  $clear: function() { ... }
});

Function $attached here has special meaning – it gets called by the Behaviors engine when the element gets this behavior attached. The params here is a parsed version of the params DOM attribute that allows to parametrize instance of the behavior for the element. For example particular instances of a slider may have different initial settings:

<span id="first" class="behavior uix-slider" 
     params="min:0, max:100, values:[15,50]" />
<span id="second" class="behavior uix-slider" 
     params="min:10, max:200, value:50" />

Input behaviors, concept of the value. The "x-form" behavior.

In principle there are two distinct types of behaviors:

  • input behaviors – behaviors of elements that have a concept of the value. Input elements have at least these two methods:
    • method $value(v) – getter/setter of the value.
    • method $clear() – clear the value – revert it to the initial, markup declared state.
  • UI behaviors – behaviors implementing various UI effects like "click here – expand/collapse there".

The $value and $clear methods are used by the x-form behavior for gathering and setting values of input elements it contains. The x-form element is by itself is an input element (compound one). Its value is a map of name/value pairs – values of standard inputs and elements that have input behaviors attached. Behavior x-form can be assigned to any container that has inputs and call of its method $("#my-form")[0].$value() will give collection of values that are e.g. ready to be send over the AJAX.

The x-form and individual input behaviors may also implement concept of $validate() – that is not implemented yet but planned.

Demos

Here is couple of demonstrations of the approach:

  • jq-ui.htm – demo of jQuery-UI widgets wrapped into input and UI behaviors (implementation: jquery-ui-behaviors.js).  Also demonstrates use of x-form to gather/set/clear form data and dynamic html loading with behavior assignment.
  • std-behaviors.htm – purely declarative sample. Demonstrates x-checkbox behavior – is a input and UI element that can be bound declaratively with show/hide of "buddy" elements. Uses std-behaviors.js – implementation of the x-form and x-checkbox.

References

  1. The Sciter – an embeddable HTML/CSS/Scripting engine;
  2. TIScript language – JavaScript++ if you wish. Used in Sciter.
  3. Behaviors in Sciter, part I, part II and part III