Delegates in JavaScript. Now with parameters.

Here is an extended delegate function:

  function delegate( that, thatMethod )
    if(arguments.length > 2)
      var _params = []; 
      for(var n = 2; n < arguments.length; ++n) _params.push(arguments[n]);
      return function() { return thatMethod.apply(that,_params); }
      return function() { return; }

And here is an example. Note that obj.method now accepts additional parameter p

  var obj =
    name: "someName",
    method: function (p ) { alert( + ":" + p );  }

  function testIt()
    window.setTimeout( delegate( obj, obj.method, "parameter!" ), 1000 );

Example of the delegate is delegate-test.

Note: this is so called parametrized delegate - parameters defined at the point of construction of the delegate - in delegate() call per se.

If you need delegate that will be inoked with parameters supplied by the caller you should use this one:

  function delegate_cp( that, thatMethod )
      return function() { return thatMethod.apply(that,arguments); }

So caller will call it as:

  var d1 = delegate_cp( obj, obj.method );
  d1( param1, param2 ); /* parameters for the delegate
           call provided at the point of invocation. */

Java GUI executable without JRE… Are you kidding me?

Three years ago (or so) I did experimental project named J-SMILE to prove that it is possible.

Main idea of it is simple – to create as small as possible Java (Virtual Machine) that can be attached to compiled Java bytecode (.class files).

Physically J-SMILE VM is an .exe file of size 200k. These 200k include:

  • Waba VM extended to support Java 1.2 language specification pretty much in full – green threads, copying GC, float support.

  • Set of native GUI functions (Graphics, Font, Window, etc).

  • Special class loader capable to load class files from trailer – .class files packaged and attached to the end of the exe file of J-SMILE VM.

I have designed mini set of GUI primitives (Widgets) like listbox, editbox, etc. and created this simple demo application:

This demo application is about 400k = 200k of J-SMILE VM + all classes needed to run it ( mini version of java.lang.* and smile.* ). Source code of class files used in this application is here.

No JRE/VM version checks, no installation step needed, self-sufficient… Cool, eh?

And now goes the question: why all Java GUI solutions so monstrous and heavy?
Premature Generalization, eh? Got Deja Vu reading excellent Eric Gunnerson’s C# Compendium.

Delegates in JavaScript

Simple definition:

  • delegate is a value – reference to the pair of object and its method. Lets name them as delegate.object and delegate.method.

  • delegate invocation is a way of calling of delegate.method in context of delegate.object. So inside code of the delegate.method variable this points to the delegate.object.

To be practically useful delegate in JavaScript must be implemented as a reference to function so, for example, we can say:

window.setTimeout( delegate( obj, obj.method ), 1000 );

and obj.method will be invoked one second later with this referring to the obj.

Here is probably simplest possible implementation of such delegate function in JavaScript (and in TIScript):

function delegate( that, thatMethod )
return function() { return; }

It returns reference to the function-thunk ( delegate per se ). This function-thunk being called will invoke thatMethod in context of that object. This implementation employs the fact that namespace of inner function in JS includes namespace of outer function.

Technically this means following: call frames in JS are also (GC-able) objects and body of the function (callee) has access to the frame of caller.

H-SMILE core. Popup and context menus (HTMLayout and Sciter engines)

For references in this article use std-menus.css file.

Popup menus

Popup menus are designed as set of behaviors menu-bar, menu and popup-menu. As always in the engine behaviors are applied to the DOM elements by CSS attribute behavior.

Menus in the engine are ordinary DOM elements thus can be styled in full by using CSS declarations. The behaviors handle mouse and keyboard events allowing to do navigation through menu items. Content of menus is not limited by only menu items – you can use any reasonable markup inside including input elements. By using input elements it is possible to implement lightweight property sheets by using engine. See Context Menus section.

Continue reading “H-SMILE core. Popup and context menus (HTMLayout and Sciter engines)”

Sciter. Part V. Platforms

Platforms supported and planned to be supported by Sciter:

  1. Currently – all incarnations of Windows (starting from Win98 SE and Win NT4). Desktop and Mobile.

  2. Planned – all incarnations of X-Windows. Desktop and Mobile.

  3. Planned – Mac OSX.

No plans to support current versions of Symbian OS and Palm OS

Sciter. Part IV. Does European-Computer-Manufacturers-Association-Script sound good enough for you?

That was the question being asked from the very beginning. The short answer is yes.

In our opinion ECMAScript ( a.k.a. JavaScript ) is probably the best scripting language if it will be discussed in the context of web client execution environment.
Well thought and designed. Documented excessively. Relatively simple in implementation. Uses flexible and universal prototype-based schema allowing to use JavaScript as both: functional and object-oriented programming languages. Already known to broad range of developers. Why learning is a curve by the way? (rhetoric question, forget it)

Continue reading “Sciter. Part IV. Does European-Computer-Manufacturers-Association-Script sound good enough for you?”

Sciter. Part III. Do you behave well?

All < input > and < widget > elements (and their subparts) in the Sciter/HTMLayout are plain DOM elements with attached behaviors. This probably sounds not too much spectacular but, trust me, this, as a system, is extremely useful.

As a rule behavior as an entity is some class or collection of functions defining guess what? correct – behavior of DOM element – how it reacts on UI events. Main purpose of the behavior is to change state of the element while handling UI events. By changing state registers of the elements behaviors allow CSS engine to style them declaratively. So for example: li:expand > .details { display:block; transition:slide } will make items in your list expandable. You just need to define proper behavior for your list like ul { behavior:expandable-list; }. Image on the right is a screenshot of that expandable-list in action.

As I said before all built-in input elements in Sciter implemented as behaviors. While loading HTML document engine styles shape and behavior of elements by using Master style sheet.

By using cascading of styles you can redefine look-n-feel (literally) of all elements. As an example of why you would need this consider following task: there is no such thing as < button type='checkbox' >some caption here< /button> by defult in HTML. But you need it! Standard CHECKBOX in Windows for example has clickable caption erea. And your customers will expect such behavior. So in Sciter you will define button[type=”checkbox”] { behavior:checkbox; … } plus bunch of state styles and you will have checkbox button visually styled as a standard system one or as a product of cauchemar of your graphical designer. And by the way, you can change its style on the fly by changing, say, value of some attribute and use the value of such attribute in CSS selectors for such elements.

Sciter. Part II. Hey, where is my old tape recoder?!

Pure HTML on the screen is a sequence of blocks spanning full width of the window (a.k.a. view) and stacked one by one forming “tape” of blocks. Tape as a geometrical surface has only one fixed dimension – width. Length of the tape is unknown at the moment of loading of HTML document. That is why there is no such thing as height=”100%” attribute/value in HTML specification. At all. By design. Nothing to calculate percentage from.

As a consequence: there is no vertical alignment of content in standard html (execept of table cell content but this is separate story) .CSS follows this path too. Yes, it defines such things as height:100% but be careful – sometimes height:XX% there means XX% from the width of the element it applied. In other cases trying to define something as { height:100%; padding:10px; } will give you effects not exactly you wanted. Have you ever seen in stylesheets something like height:99%? I bet – you did. Do you think author wanted element to be exactly 99%? I am pretty sure – no.

In many UI design cases you do need to say: I want this element (panel, block, etc.) to span the whole available height of the form/window/view. Take a look on the window of your favorite browser as an example. Can you define its window layout in HTML? … And hey! Don’t touch < table >s !!! They are designed for tabular data representation only (as they say). Anyway you cannot use such thing as < table height="100%" > in standard HTML. Well, you could of course give it a try but nobody will tell you what this height=100% means. 100% from what? Not defined, non-standard – not reliable to use.
Continue reading “Sciter. Part II. Hey, where is my old tape recoder?!”

Sciter. Part I. So what is the Sciter anyway?

Hard to say… Sciter is an Offline Web Application Client (I can feel smell of tautology in Offline Web). In other words it is Excution Environment for Occassionally Connected Web Applications. (Last definition is significantly better, isn’t it?)

And here goes the same as above but in plain English (or in what I assume is English) language:

You may think about the Sciter as a Web client application (some smart people use name User Agent – UA) of special kind. “Special” here means that Sciter as a web client is capable to work in offline (disconnected) mode too. What’s the deal you will ask? Everyone can click on icon of his/her favorite UA and browse pages stored on his/her local drive. But… this is pretty much all of what you can do with standard UA. Not too much, isn’t it?

Continue reading “Sciter. Part I. So what is the Sciter anyway?”