We have published official proposal about ‘flow’ and flex units used in h-smile core:
CSS Flexible Flow Module

With the hope that the Web will benefit from them.

I have published article comparing TIScript and JavaScript on CodeProject. That is a “big picture” if you wish.

I have written this article completely in the ScApp (Sciter Application) named BlockNote for the Net:

Screenshot of BlockNote ScApp

It is a part of Sciter SDK and reside in sdk/scapps/blocknote.net/ folder.

Eventually this will replace outdated BlockNote v.1.8 application. Plan is to create platform for comfortable content editing in Internet. E.g. as an editor it is already more convenient than built-in editor of the WordPress application I am using here.

Latest builds of the Sciter have decorators implemented. My implementation of decorators ideologically derived from the same decorator feature in Python of Guido van Rossum.

Decorators is a meta/macro-programming feature that allows to transform or update function or class defined in source code.

Here is an example: say we are designing some dialog with various input elements and buttons. Usually code behind such dialogs is a collection of simple “if-we’ve-got-some-event-here-then-update-state-over-there” blocks. First part (if-we’ve-got-some-event-here…) of the task is repeating again and again. The desire is to make it as short and clear as possible. With decorators this could be written as:

@when Event.BUTTON_CLICK @on "button#add-new" :
   {
      this.select("#list").insert( new Element( "option", "new item") );
   }
@when Event.SELECT_SELECTION_CHANGED @on "select#list" :
   {
      this.select("#delete-current").state.enabled = true;
   }
...

This makes such sequence of blocks to look more like a table of records: when (event) on (where) (then do this). That is more declarative approach if you wish. This code is better maintainable I think.

@when and @on here are decorators of anonymous function that follow them. ( Sequence :{ ... } declares anonymous function in TIScript ).

Decorator in TIScript is an ordinary function with the name starting ‘@’ and at least one parameter. This first parameter is a reference to function that is being decorated. Decorator-function in its turn can dynamically create another function that will wrap call of original function.

Here is how our @when and @on decorators might look like:

// decorator '@when' - filters event by type
function @when(func, evtType)
    {
      return self.onControlEvent = function(evt)
         {
           if( evt.type == evtType)
              return func.call(this,evt);
         }
    }

// decorator '@on' - filters evt.target by the selector
function @on(func, selector)
    {
      return function(evt)
      {
        if( evt.target.match(selector) ) // if target element matches
          return func.call(this,evt);       // the selector call the func.
      }
    }

As you may see both decorators simply create wrapper functions that filter the event using different criteria. Thus following statement:

@when Event.BUTTON_CLICK @on "button#add" :{...code...}

simply establishes chain of filters that ends up with the call of code that handles the event.

Syntax of decorators in TIScript is described here.

Richmond, British Coulmbia, Canada. Yesterday:

Usually business applications are split in three tiers: user interface layer (UI), business logic layer (BLL) and data access layer (DAL). That split is also known as Model-view-controller architectural pattern.

Ideally each layer should be isolated from the rest. For many good reasons. In any case each layer operates using its own vocabulary (namespace if you wish). For example “Account” in UI means some set of fields (<fieldset> literally). In BLL it is an instance of some class with attributes and methods describing logic. And in DAL it could be just a record in DB with associated triggers and stored procedures.

Code that works on each layer(domain) is serving different tasks. Ideally each such layer may require different programming languages that are optimal for each particular layer. E.g. DB layer as a rule uses TSQL as it better suits DB manipulation needs.

The same thing is about UI. Usually UI tasks are just sequence of rules like “if user clicks here than enable that thing over there”. Such tasks may or may not be handled equally well by universal languages like C++.

Ideally UI layer should have its own language that is better suitable for UI needs. In the same way as DB has its own language (couple of them actually: DB schema definition language and transaction definition language).

class MyWidget: Behavior
{
  function onFocus()
  {
    var me = this;
    // bind toolbar buttons to this widget methods:
    self.$("button#save").onClick = function() { me.doSave(); }
    self.$("button#new").onClick = function() { me.doNew(); }
    self.$("button#open").onClick = function() { me.doOpen(); }
  }
  function doSave() { ... }
}

After many years of designing various UI and UI toolkits I shall admit that UI automation/programming is not quite OOP task in general. Usually it is better describable in terms of something close to functional programming but with the ability to define classes/objects.

UI is an assembly of sometimes very different UI components/controls. That requires language that is flexible enough to glue them together. That is my vision on TIScript in Sciter.

And of course markup and CSS are also Good Things for the UI. Especially CSS.

Comparing taxes in US and Canada I came up with the following:

Either you need higher taxes or you need to allow retail trade of guns.