We can externalize the intelligence of applications in servers and easily make updates, while having any terminal consuming them with a minimal OS environment.
Cloud or whatever you call it, it’s awesome.

WOA is our common architecture for making applications. Clients of web servers can be anything you want, not only desktop browsers, but also mobiles, tablets, other web services, and… command-line!

And today, as an example, we will use Google Closure Compiler web service to minimize a Javascript file with only cURL.

cURL is a CLI swiss army knife of transferring data and it is perfect for testing, debugging and consuming web services.

Google Closure Compiler check and “compile” your Javascript file. By compile, it means optimizing its size by renaming variables and removing spaces and comments. Javascript compilation has because an essential phase of major javascript libraries.

Bash script examples

Download and minimize the last version of Illuminated.js

Minimize a local JS file

Click on the image to open it!

Wow! what’s this?

It’s a 2D scene containing 2 lights and 13 different objects rendered in real-time by a Javascript library I made called Illuminated.js.

The library is designed to add some awesome effects to your existing applications. Adding a cool atmosphere for your applications and games can make the difference!

Try the editor and Get the source code.

In this article, we will introduce the basic usages of Illuminated.js and APIs, and then explain how the engine works step-by-step.

• API – Getting started
• Technical notes – how does it work?

How can I use it?

The library uses HTML5 Canvas to draw lights and shadows – so you can simply drop it straight into your existing Canvas applications: you just need to add some code in your render function and maintaining a binding between your application logic and the Illuminated.js objects.
Not using canvas? No worries! In theory, if you have an existing application or game made in full DOM, you could use Illuminated.js behind this, playing with z-index.

Getting started

Basic concepts

All the classes of the package live in window.illuminated.

A Light describes a light emit source.
An OpaqueObject specifies an 2D object used by a Lighting.
A Lighting defines the lighting of a light through a set of opaque objects, each object stops the light and casts shadows.
A DarkMask defines a dark layer which hides dark area not lighted by a set of lights. It should be drown on the top-layer to hide objects which are far from the light. This effect produces a better atmosphere and is perfect for game where light are essential (where hiding invisible area is part of the difficulty).

Example of a basic scene rendering

Click here to open this example.

Lights and Objects

Vec2

Vec2 represents a 2d position or a 2d vector. It is used everywhere in Illuminated.js.

Vec2 is inspired from Box2d’s Vec2 except that in Illuminated.js a Vec2 vector is immutable. It means every methods create a new Vec2 instance and you can safely use a same Vec2 instance everywhere because the immutability guarantees the non-modification of properties.

Lights

For now, we have only implemented one kind of light: a Lamp which is basically a radial gradient. A Lamp can also be “oriented”, it means lighting more far in a given direction.

Lamp

every parameters:

It defines a Lamp placed at a position, with a maximum emiting distance, a diffuse parameters to define the light penetration in objects.
The radius defines the size of the light. Bigger the size is, Higher shadows are smoothed. The samples is an important parameters to define the quality of this smooth.
The angle and roughness parameters are used for oriented lamp: angle defines the orientation while roughness defines the roughness of the effect.

Light methods

You can easily create your own Light type by implementing its methods.

.mask(ctx)

Render a mask representing the visibility (used by DarkMask).

.render(ctx)

Render the light (without any shadows).

.bounds()

Return the Rectangle bound of the light representing where the light emission limit. { topleft: vec2, bottomright: vec2 }

.forEachSample(fn)

Apply a function fn for each light sample position. By default it’s called once with the light position.

Opaque Objects

In Illuminated.js, an object which cast shadows is called an opaque object. That’s why every types inherits OpaqueObject.

DiscObject and PolygonObject are the two available primitive objects.

DiscObject

A “DiscObject” is basically a 2D circlar object. You must define its center position and its radius:

PolygonObject

PolygonObject also has some derivated classes you can use: RectangleObject, LineObject.

You can instanciate these different objects like this:

OpaqueObject methods

You can easily create your own object type by implementing OpaqueObject methods.

.bounds()

Return the Rectangle bound of the object. { topleft: vec2, bottomright: vec2 }

.contains(point)

Return true if the object contains a point.

.path(ctx)

Build the path of the object shape in a 2d context ctx.

.cast(ctx, origin, bounds)

Fill every shadows with ctx projected by the origin point in the object and in a given bounds.

Lighting and DarkMask

Previous defined classes was representing datas we will now use to perform lightings and masks.

Lighting

A Lighting defines the lighting of one light through a set of opaque objects.

.compute(width, height)

will compute shadows casting.

.cast(ctx)

will draw black shadows on the ctx canvas 2d context.
You usually don’t have to use it if you use render().

.render(ctx)

will draw the light with its shadows on ctx canvas 2d context.

DarkMask

A DarkMask defines a dark layer which hides dark area not lighted by a set of lights.

.compute(width, height)

will compute the dark mask.

.render(ctx)

will draw the computed dark mask on ctx canvas 2d context.

about compute and render

Both Lighting and DarkMask objects have compute() and render() methods.

We think that you know the best when to recompute the lights because it’s closely link to the application you are making (we will not check at each time if something has changed, you know it).
Call the compute() method when something has changed in your scene so we can recompute lights and shadows.

How does it work under the hood?

Illuminated.js divides its work into several layers.

Real-time example

The art of composing layers

The layers are all stored in a Canvas which allows us to cache it. The light is drawn using a Canvas Radial Gradient in a cache canvas only once. This is interesting because canvas gradient are processor intensive
At the end, layers are combine on the global canvas with drawImage.
But the library lets you reuse these layers to combine them the way you want.

Canvas’ globalCompositeOperation is very useful to compose layers together.
For instance, in the following example, the “Light shadow casting” layer is combined with the “Light rendering” layer to generate the “Light rendering with shadows” layer. The composition mode used is “destination-out” which remove the color of the destination image where the source image has color.

Another very useful composite operation is "lighter" which adds color values. It is used to combine two lightings.

How shadows are projected

Some rendering engine use ray tracing to render a scene, a concept very close to physics which trace from a light source a lot of rays with different paths which will collide with object and will be subject of absorption/diffraction/reflexion in accordance with the object properties…
Ray casting is a very realistic rendering solution but consuming (you need a lot of rays to avoid noises in the result image).
Illuminated.js doesn’t use ray tracing because it aims to be efficient for a real-time usage. It uses some heuristics for casting shadows.

Let’s see how shadows are projected for a polygon object.

We have a scene with a light and a triangle.

We select each edge of the polygon which is visible by the light (and in the light bounds).

For every selected edge, we project it to generate a polygon area.

N.B. In the current implementation, we generate an hexagon projection to ensure it goes outside of the light bounds because a quadrilateral didn’t garantee it, if a light is very close to it. The projecting vector used is enough big to work for most case, but it’s still an heuristic.

We draw black color in this polygon area. Some improvments can be made by not drawing black in the shape / ajusting the opacity of the color.

For casting blured shadows, we repeat this algorithm for each “samples” of the light. Samples are distribute around the light with a “spiral algorithm”.

To be continued…

The current version of Illuminated.js needs more work, I’m aware of some bugs and some parts I need to improve:

• Implementing new kinds of lights like “Spot”, “Neon”, …
• The dark mask doesn’t follow the Lamp orientation.
• The shadow casting of Circle objects are not projected nicely, I need to compute tangent lines to the circle.
• Shadows go sometimes wrong especially when having objects behind objects
• The shadow sampling implementation is a bit hacky and wrong (changing the samples parameter changes the shadow opacity…)

Get involved

Try the editor and Get the source code.

HTML5 now have the <input type="color" /> and <input type="range" /> which is nice. It works on Chrome and there are some polyfills to make it working on older browsers.

We will now see how we can easily retrieve a rgba color from such an UI, regardless of the color format given by the color picker and combine the alpha component from the alpha range picker.

We can implement an anythingToRGBA converter in 10 lines of Javascript!

What?

Basically, for instance, you have this: "#ff6432" and 0.8

and you want this: "rgba(255,100,50,0.8)"

which is this color:     .

Well, of course, we could use a library with regexp parsers!

But there is a lot of different formats available especially if you want to convert a color from CSS!

Only for the blue color, you have at least 7 different representations: #00F, #0000FF, rgb(0,0,255), rgba(0,0,255,1), hsl(255,100%,50%), hsla(255,100%,50%,1),
and… blue!

Ouch, so let’s make a huge converter library!

Nope!

All of these are color formats are supported by CSS and also Canvas.
So, why not just re-using what the browser can do?

How?

Because we have access to Canvas in Javascript, we can implement an anythingToRGBA converter in a few line of Javascript:

You have now a ready to use Javascript color library!

getRGBA("#ff6432", 0.8) will returns "rgba(255,100,50,0.8)".
getRGBA("red", 0.5) will returns "rgba(255,0,0,0.5)".

You can “standardize” your color and use it anywhere!

Feel free to adapt the code to any other desired format.

We can easily make the reverse (give a rgba color and get the #RRGGBB and alpha values):

How cool is that!

It is perfect for making web applications loading bar in just one line of HTML and a few Javascript code.

A progress tag will be displayed on recent browsers with a OS-native progress bar representing a loading. Like many HTML tag, if it is not supported, it fallbacks nicely by displaying its inner content. This fallback content should either be your own designed progress bar or simply display a percentage.

It is today supported by Firefox 9+, Chrome, Opera and IE10.

Example

On your browser:

On Linux / Firefox (with GNOME)

On Mac OS / Chrome:

On IE 6:

Let’s see some cases:

waiting

<progress max="1000"></progress>

starting

<progress value="0" max="1000"></progress>

in progress:

<progress value="500" max="1000"></progress>

finished:

<progress value="1000" max="1000"></progress>

Making a download bar

When you need to load big resource like images, videos, or 3D materials, you usually want to display the progress of the download.
You could still do it using some divs and CSS + Javascript, but this is now much simpler to use a <progress /> :

One line of HTML:

And the Javascript:

(for more convenience, we are using jQuery)

It is quite easy to extend my code to support multiple files to download.

It is also easy to use this progress bar for anything else, but remember it represents a progress. If you want to represent some kind of stats, refer to the dedicated <meter /> tag.

We can distinguish two kinds of 2D games:

Tile based games where the game world is simplified with a big grid – each grid position has some properties.
A map editor is not always needed for tile based games, because the map can be straighforward to represent and maintain like in a Bomberman or in a Pacman. A simple editor is generally used to make graphism with sprites.

Non-tile based games, which can be called “polygon based games” are more complex.
In such game, like a Worms or a Sonic, it’s totally crazy to write the map by hand (objects positions, polygons coordinates, …). The alternative, is not to use predefined maps, but on-the-fly generated maps which doesn’t fit every games.

Making the game engine is one thing, but designing the game levels can be one big work too and we need tools to make it easier.

Tile based game maps

In tile based games, maps are usually quite simple to represent.

For instance, here is how we can code the maze of Pacman:

where every character is a tile and has a given meaning.

For more complex games, we can also represent the map with a set of objects, and each object has position and size properties (x, y, width, height) and other properties for the game logic.

For instance, see the ImpactJS tile based games editor:

But what about polygons based game?

Well, some have tried to make dedicated 2D game map editor like shown in this video:

but it sounds a bit unfinished and specific.

Do it yourself, but don’t reinvent the wheel.

But finally, isn’t it what a 3D editor is doing?

Isn’t it the most generic tool we can find?

They have done a lot of awesome work in term of user interface, polygon modeling, textures (procedural / bitmap), …let’s profit of all this work to generate awesome texture map while exporting polygons.

Relying on such tools, you don’t have to learn a brand new map editor, you can relax on what you know if you have the chance to know Blender or Maya or anything.

The Z magic

Let’s ignore the Z dimension, or rather, let’s use the Z-dimension as a way to represent the semantics of the game map!

This is the map I made for Blazing Race, a HTML5 against-the-clock platform game where you control a fireball:

For my game needs, I used different Z layers to represent different kind of materials and game objects:

• z=1 : candles’ position – the objective of the game is to light them all
• z=0 : the game grounds – where collision occurs
• z=-1 : the water areas – where your flame dies
• z=-2 : special areas where you miss oxgyen – your flame dies in a few seconds

But I also used objects ids as an another way to distinguish objects:
a “start” object to define the game start position and two “topleft” and “bottomright” objects to define the game bound.

Maintain your map source in one file

Another powerful feature of this, is you can maintain your map polygons AND your map textures in a single way. Use your 3D editor as a polygon editor and use its render engine to generate textures:

Take benefits from what your 3D editor can do.

Export polygons to the Javascript game

I’ve made a transformer which take a COLLADA file in input (the most commonly supported standard format to describe a 3D scene, you can export it from any 3D editor like Blender, Maya, 3DS…) which extract and transform relevant informations from it and give you a json map for your game in output.

It was quite simple to implement, thanks to the Three.js COLLADA importer

Here is the current (unfinished) interface for this:

As a proof of usability of the output JSON map, the preview was only made in a few lines of Javascript code.

Extract:

What is next?

Blazing Race, is not finished yet, I need to improve a lot of things

I’ll try to release a standalone version of this converter soon with tutorials and examples.

Thanks to everyone having tested my Play Painter experiment, you helped me figure out bugs and bottlenecks and to benchmark the application running on my tiny server.
The first version of Play Painter has been improved with some optimizations.

Explanation…

In brief

• 80 twitts, 3500 unique visitors in a few days.
• a peak of about 80 simultaneous painters.
• about 200 WebSocket messages per second when 3-4 users are drawing => bottleneck found.
• when it occurs, 100% CPU and about 1500 system interrupts per second on my poor Atom 1.2 Ghz server.

Some reasons

The initial version of Play Painter was a basic fast-prototyped version:

First, It was spreading every mouse events (down, up, move) to all clients as fast as it comes. It means that, depending on the computer and browser performance, a huge number of events could have been triggered and spread to all connected users.

We solved this by Chunking draw events.

Second, a lot of informations was repeated in WebSocket messages. No datas were stored on the server-side so to be sure a new user see the right draws, player name, brush color and size was sent in every message. Multiply this by the number of mouse events and you get a lot of useless information!

We are now Storing painters information.

Chunking draw events

When an user starts drawing, mouse events give the brush positions (x, y). But instead of sending a websocket message for each of these new positions, they are stored, and every X milliseconds, are sent in a websocket message. Such message contains all points of the draw from the last sent draw message.

The X value has currently been fixed to 50 milliseconds because it’s enough for the human eye: It means about 20 messages per second for one painter. In movies we usually have a 24 frame rate.

The same principle has been applied on the painter brush positions.

Example

Before
13 WebSocket messages:

After
2 WebSocket messages: (50 ms apart)

To a variable frame rate?

I am also thinking about a variable rate depending of the number of active painters. In fact, the more we have painters, the more we will have messages, and the more the server will have system interrupts, we could then decrease the frame rate per second to reduce this load.

The problem of this extreme approach is the degradation of the feeling of real-time.

For now, I’m keeping the constant frame rate version, we will see how far it goes.

Storing painters information

As I said, a lot of informations was repeated in WebSocket messages. In every draw events, painter name, brush size and brush color was sent from the client to the server, and the spread into all connected clients.

This was ok for prototyping but we have now optimize this by storing these painter generic informations in the server and sending them when a new WebSocket connection is opened.

Example

This is what a client can receive when a websocket is connected:

and then…

By knowing all painter properties, when someone will draw something, he will not have to repeat which color and size its brush has.

Server side

It was quite interesting to implement the server part with Play2′s Iteratees, a new way of handling I/O – not so new in fact because it is directly related to Haskell Iteratee concepts.

To implement a WebSocket connection, you will provide an Iteratee for consuming the input and an Enumerator for producing the output.

Enumerator are chainable, this is how I firstly send the painter id and painters informations:

The >>> operator is a shortcut to the andThen method which is the way to chain enumerators.

For more details, see the scala code of the controller.

Other features

The application has been improved in many other ways.

• A “buffering” Canvas in the foreground has been add for the user draws. It brings client-side reactivity and helps to avoid unpleasant lag feeling when drawing. When the user draw events are coming from the server and no other user events has been sent since, it’s synchronized and we can clean this buffer.
• Painter positions are show with their names.
• It should now work properly on smartphones and tablets. Try on iPad and iPhone, and maybe on recent version of Android (WebSocket support required).
• Keyboard shortcut: using arrows to change brush size and color.
• The source code has been polished and commented especially the server side part (it’s probably the hardest part if you don’t know Play framework).
• Error message displayed when a technology is not supported and when the WebSocket connection goes down (with a reconnecting try loop).

The demo is still online!

greweb.fr:9090

Future

With these two optimizations, I’ve reduce the global number of socket messages and also the size of each message.

The first benchmark sounds good, 3 painters was simultaneously crazily painting while the server application was only using less than 10% of CPU.

Now, the most challenging part would be to scale the application to a huge number of connections, but having maybe solved this bottleneck, it’s maybe now more a matter of system architecture than the application itself.

This experiment gave me a lot of interest in WebSocket and also in the powerful way WebSockets are handled in Play framework.

If anyone want to start a Java version of the application, please go on! (this was requested on Github)

Thanks to @dbathily, we know have both Scala and Java version!

Next experiment

I am thinking about making a multiplayer game on the web.
It would be something like a shooter survival game (like Counter Strike Zombie Mod) + a multi-plateform 2D side view game (like Mario) !

You will know more about this soon

I will show you how to implement a multi user paint using latest web technologies like Play framework (version 2), HTML5 Canvas and WebSocket.

Let’s see how to implement this from scratch in about 30 minutes…

and read how I’ve improved this initial version…

or try the demo below…

Fork me on Github.

Most of the time, data ranges are unknown, hence we need to adapt the grid step to provide the best display.

Check this out

Let’s explain the algorithm…

About scientific notation

Any number can be formatted in scientific notation. It is written in the form of A x 10^N and is noted AeN.

For instance, 2300 becomes 2.3e3 (because 2300 = 2.3 x 10³), 12 becomes 1.2e1, and 0.23 becomes 2.3e-1.

Scientific notation is exactly made for displaying huge or tiny values in a few characters.
We can use the same principle for finding good values for the step scale, we can just keep the pow of 10 part (N) and round the value part (A).

Magic numbers

But rounding is not enough, I have found that good pattern numbers of step range is those divisible by 2, 5 and 10.

In math term, we need to find a step range sr, where

This is basically because 2 x 5 = 10 : using a step of 5 we have a 10 modularity every 2 step, and, using a step of 2 we have a 10 modularity every 5 step.

2 step: 0 2 4 6 8 10 12 14 16 18 20 …
5 step: 0 5 10 15 20 25 30 35 40 45 …
10 step: 0 10 20 30 40 50 60 70 80 90 …

For any dataset, we need to fallback on the closest step range in all of possible step ranges: … 0.002, 0.02, 0.2, 2, 20, 200, …, … 0.005, 0.05, 0.5, 5, 50, 500, …, and … 0.001, 0.01, 0.1, 1, 10, 100, …,

Calculate the pow of 10

To get the N value of the A x 10^N form, we can use the log of 10:

Calculate the value modulo 10

To get the A value of the A x 10^N form, we can just divide the number by 10^N:

‘Rounding’ the number

We know just need to change the value of A and make it more “readable”.
We can map the value as follow:

Note that these rules may probably be improved, I would love if someone could improve this (because I use a arithmetic mean approach and it should probably be arithmetic).

Implementation

Scala

Javascript

Usage example:

where xMax is the scale of the axis, and 10 is the desired number of graduation split.

Conclusion

Finding the best grid step is finally a simple thing to implement but is an essential feature every chart libraries should have.

Many animation libraries are today using easing functions – functions of time returning a progression percentage value. This is required to perform such cool effects:

But most of these libraries implement a huge collection of functions. We will see how we can generalize them with bezier curves.

For instance, we use to do this:

Defining such functions is lot of math fun but it is very specific and not really customizable. Hopefully, we can generalize these easing functions. With Bezier curves.

In fact, this work has already been done in CSS Transitions and CSS Animations specifications! You can use transition-timing-function CSS property and give a cubic-bezier(x1, y1, x2, y2) value (all ease, linear, ease-in, ease-out, ease-in-out values are just fallbacking on this cubic-bezier usage).

In a bezier curve based easing function, the X axis is the time axis whereas the Y axis represents the percentage of progress of the animation.
The two points P1 and P2 are called handles and you can (exclusively) control their X and Y positions to generate every possible cubic timing function.

Live demo

Try to interact with the handles:

Implementation

Ok, so, this bezier curve concept is great but how can I implement it?

I’ve read here how simple is it to compute many points of a Bezier curve and potentially draw them:

But it’s not enough. We need to project a point to the Bezier curve, in other words, we need to get the Y of a given X in the bezier curve, and we can’t just get it with the percent parameter of the Bezier computation.
We need an interpolation.

Deep into Firefox implementation

In Mozilla Firefox, The bezier curve interpolation is implemented in nsSMILKeySpline.cpp : https://gist.github.com/1925793.

What we can learn from it is:

• A first optimization store sample values of the bezier curve in a small table used to roughly find a initial X guess.
• Then, it use two different implementation strategies: One use the Newton’s method and the other is just a dichotomic search (binary subdivision).
• A criteria based on the slope give the best strategy to take.

These sub-optimizations probably make the difference for the C++ version but are not really relevant for the JavaScript implementation. Moreover, I have only used the Newton’s method algorithm.
And this is the code:

Now we can just alias some classic easing function – like CSS does.

I’m working on the next version of Slider.JS which relies on 3 different technologies for image transitions: CSS Transitions, Canvas and GLSL shaders (from WebGL).
I have now found a common way to describe easing functions for both CSS-based and Javascript-based animations!

This example has shown that sometimes, finding a larger solution for a problem is more interesting than having specific solutions.
This is called the Inventor’s paradox.

What is CSS ?

CSS is an extremely powerful descriptive language.
It helps to define how to display a document (e.g. a web page).

A style sheet contains a set of CSS rules.
Each CSS rule has a CSS selector associated with a set of declarations.
You can see a CSS selector as a selection filter applied on every HTML element. A few element can match a CSS selector if they fit the structure describes in this selector.
Each declaration is composed of a couple (property : value).
The CSS property is a predefined property related to a display or layout behavior.
The value will apply a custom value for the property on all elements matching the CSS selector.

Let’s focus on some advantages of this descriptive language:

A CSS rule is independant from others.

The order of CSS rules (selector + declarations) really does not matter.
The priority between CSS rules is based on the selector itself and not on their arrangement.

You can “mix” CSS rule

2 CSS rules can have the same CSS selector. An element can be matched with multiple CSS rules. CSS rules are merged, it’s called the cascading.
This is the most important feature of CSS.
It implies a very modular and extensible language.

Example

Some limitations of today’s template system

Most of template system are based on inherence between templates.

• You have usually an “inclusion” approach: a template will “include” multiple external template. (Many template into Many template)
• And an “extension” approach: You define in a main template an area where you can append a template. Others templates “extend” your main template. (One main template for Many template)

These approaches aims to factorize template codes and that’s great.

But it doesn’t fit my needs:

• It brings dependencies between templates.
• If you add a new template, you have to modify existing templates.
  If your application tend to go modules based, this is going to be unmaintainable.

web application module (n)
1 : an independent unit of functionality that is part of the total structure of a web application

A solution for scalable applications and libraries

I’ve recently started to rewrite my SliderJS library and I needed to split it into very modular features and having loose coupling between each component.

I followed this Scalable JavaScript Application Architecture article.

So, how to bring loose coupling in templating?.
Each module have its own template and know where to append. Bringing this logic in a main template would break the independency and if I need to add new modules soon, it will not working without modifiyng it.
How to keep the scalability of the main template without modifying it?

The best solution I found is to combine CSS selectors concepts with template system approaches.

CSS concepts applied on templating

I’ve decided to inspire from CSS: attaching a CSS selector with a template.
It benefits from some CSS advantages explained before.

Simple twitter widget example

Classical approach

The way to template it with the classical approach would be:

CSS selector based approach

But we can also split the original “template” in small fragments and mix all of them.
It helps to define each templates independently.

We can identify:

- A root template fragment:

- A header fragment appended with .twitter selector and with an high priority:

- A twitts list fragment appended with .twitter selector:

with parameters twitts = [ "Hello world!" ]

- An empty footer fragment appended with .twitter selector and with a low priority:

- A “follow me” link fragment appended with .twitter footer selector:

with parameters me = "greweb"

Advanced example

This is another example with a slider.

Let’s conceptually imagine the following template language:

combined with some parameters, it will result

Of-course we could also do this programmatically with DOM. But see the benefit of such a descriptive way to define things?

You should keep in mind that the order of rules definition does not matter. In that’s sense, it is a mixable, extensible, modular and loosely-coupled template system.

More about this POC

Unlike CSS, two same rules aren’t merged but are appended.

The priority governs the order of append. The higher the value is, the sooner it is appended to the containers selected by the CSS selector.

As you can see, there is a micro-templating inside each rule. For this example, it looks like the John Resig ‘s Micro Templating.

Note also that a rule must be aware of its parameters to work properly. But this only concerns the implementation: You have to find a way to give a dynamic reference of these parameters when you add a rule.

Concrete implementation

The code above was a conceptual proof of concept, but I implement a subset of these features in Javascript and made “SelectorTemplating.js” available here : https://gist.github.com/1731611

This is how it can be used for (almost) the same example. You will see different style of usage:

t.add (selector, templateFunction, callback, priority)
 * selector is the selector function. if null, append to root.
 * a template function is an identifier in the template.
 * the callback is called at the end of the templating with 2 arguments : the appended nodes and the global container.

Algorithm of the template process

container := the container element
rules := an array containing all rules.
sort rules by priority.
(1) take one rule from rules
  - elements := []
  - if the selector is @root, elements := [container]
  - otherwise, elements := all elements which matches the selector
  - if the elements is empty, back to (1) by taking the next rule.
  - (2) if not, templatize the html and append it into all of these elements. remove the rule from rules. back to (1) by starting from the first rules. 

the loop (1) must end when :
  - there is no rules anymore
  - you have covered all the rules array without finding a match (without passing by (2) for this loop). In that case, it means some rules are not used.

There is a known limitation of the algorithm I intend to fix soon:
Once we found matching elements for a rule, we append the template in these elements once, and we remove the rule. It’s a simple way to avoid recursion. But this approach doesn’t work if a selector can potentially matches elements defined in different rules. I know how to fix this but it’s not yet implemented.

What’s next?

We are working hard for the next version (v2) of SliderJS by trying to make a revolutionary IDE platform for SliderJS. It requires a modulification of every components of SliderJS, we try to keep things simple (no external library required, the core system is only 4k sized). You will have more information soon!

This templating system should benefits of this work.

Keep in touch!