ff javascript library update to 1.11

The ff javascript library is now available in the version 1.11 which is a small maintainance update to version 1.1

Changes are:

  • introduced ff.extend
  • made ff.dom functions ignore null arguments and handle the tabindex attribute correctly in Internet Explorer

See the documentation for the ff.extend.


Creating JSP Layouts with Page Tags

For some time now I’ve been following a new approach when creating the basic layout structure for JSP based web applications. The new approach is based on JSP 2.0 tag files and changes the way that the single pages are build up from reusable parts.

The most common way to do so is to use included files with common blocks:

<%@include “head.inc”%>

<b>page specific markup</b>

<%@include “tail.inc”%>

Here the individual pages contain two or more includes which define the page start and end. Often navigation or sidebars or whatever are included in their own files. Changing the output of the title in the header e.g. requires passing data through the page scope or so.

My new approach defines the basic layout as JSP 2.0 tag file. Let’s take a look at an example:

<%@tag description=”page layout” %>
<%@taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core”%>
<%@attribute name=”head” fragment=”true”%>
<%@attribute name=”title” required=”true” type=”java.lang.String”%>
<%@attribute name=”script” required=”false” type=”java.lang.String”%>
<%@attribute name=”stylesheet” required=”false” type=”java.lang.String”%>

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
<title>${title} – Page Tag Example</title>
<style type=”text/css”>
@import url(“<c:url value=”/style/style.css”/>“);
<c:forTokens var=”item” items=”${stylesheet}” delims=”,”>
@import url(“<c:url value=”/style/”/>${item}“);

<c:forTokens var=”item” items=”${script}” delims=”,”>
<script type=”text/javascript” src=”<c:url value=”/script/”/>${item}“>
<jsp:invoke fragment=”head” />
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
<meta http-equiv=”Pragma” content=”no-cache”>
<h1>Page Tag Example</h1>
<ul id=”nav”>
<li><a href=”index.jsp”>Index</a></li>
<li><a href=”page1.jsp”>Page 1</a></li>
<li><a href=”page2.jsp”>Page 2</a></li>
<div id=”content”>
<jsp:doBody />
<div id=”footer”>
<a href=”http://validator.w3.org/check?uri=referer”><img
src=”http://www.w3.org/Icons/valid-html401″ border=”0″
alt=”Valid HTML 4.01 Transitional” height=”31″ width=”8″></a>

The tag defines the example page layout with a page header, a navigation and a footer. There are several attributes to control the page tag from inside the JSP page it is used in:

  • head – Fragment attribute used to add additional HTML markup to the head section of the page
  • title – Required attribute which sets the page specific part of the page title
  • script – Comma separated lists of script files to include from the /script directory
  • stylesheet – Comma separated lists of style sheets to import from the /style directory

The head fragment attribute demonstrates how to setup a fragment attribute which makes it possible to set HTML code as an attribute. To use such a fragment attribute inside a page you need to use the <jsp:attribute> and <jsp:body> tags:

<%@taglib tagdir=”/WEB-INF/tags” prefix=”example”%>
<example:page title=”Page 1″>
<jsp:attribute name=”head”>
<meta name=”author” content=”Sven Helmberger”>
Page 1 – demonstrates the use of the head fragment attribute

If you only use normal (non-fragment) attributes you can leave out the <jsp:attribute> and <jsp:body> tags and specify the rest of the attributes like the title attribute above. Fragment attributes can also be useful to define common code blocks besides the tag body like a page-specific area in a sidebar or so.

You can see that, even with fragment attributes complicating things, the page tag leads to a simple JSP code with high reuse and clear passing of data from the special page code to the common code.

ff javascript library 1.1 released

After some more work on it, I am proud to announce the version 1.1 of the ff javascript library. It includes various bug-fixes ( ff.dom.append , various Internet Explorer compatibility fixes especially in the DOM builder) and some more functions in ff.dom and ff.style. The ffjs documentation moved to a new location. It includes a lot more documentation and 2 examples. I may add some more examples in the future. 

Javascript Slim-Down

Modern javascript libraries tend to be fat. This increases the page load latency, wastes bandwidth and is a real problem for people with slower connections (There are still about 50% dialup users). So trying to slim things down comes almost naturally.

In this article I will try to present two compression methods that together will make your scripts lose up to 80% of their weight and I will also present an alternative way to serve gzip compressed files with Turbogears : a precompressing gzip controller for Turbogears.

The first thing one can do is javascript compression. Stripping unnecessary whitespace and renaming local variables can already bring down the size a bit, The dojo javascript compressor ( online version ) does both.

Let’s take two of the javascript libraries used for this site as examples:

  • ff-src.js – source version of my own javascript library

    Uncompressed: 10.1 KB
    Javascript compressed: 6.7 KB
    Compression: 33%

  • tinymce.js – all sources I need from the tinymce richtext editor joined together

    Uncompressed: 329.0 KB
    Javascript compressed: 233.6 KB
    Compression: 29%

This sure is nice for a start, but we can go even one step further with gzip compression. Gzip compression is a w3 standard ( defined in RFC 2616 ) and can be used to send the output of a server compressed to a client. Using this our files shrink even more:

  • ff-src.js
    Uncompressed: 10.1 KB
    Js and gzip compressed : 2.8 KB
    Compression: 73%
  • tinymce.js
    Uncompressed: 329.0 KB
    Js and gzip compressed : 57.8 KB
    Compression: 82%

Most modern web servers allow you to enable general gzip compression. IIS does it, Apache has mod_gzip for it, Turbogears can do gzip compression via cherrypy’s gzip filter.

Personally this felt like an overkill to me. I don’t really want to use my precious server CPU cycles to compress output where it’s no larger win to do so. So I wrote myself a precompressing gzip controller for Turbogears. It creates gzipped copies of a configurable set of files and automatically updates them. If the client browser supports gzip encoding, the gzipped file copy is sent, otherwise the normal file is send.

The controller is meant to be used as a subcontroller list this

class Root( controllers.RootController ):
# subcontroller
gz = GzipController()

This would map the gzip controller to /gz/ .


  • gz.py — precompressing gzip controller
  • serveFile.patch — Update: the patch has been integrated into the turbogears distribution

ff javascript library

The project documentation has been moved.

Demo Video Archive

Back in the day when I was involved in the demo scene, I was a coder for Haujobb and did some demos / intros for the Amiga1200. Demos are realtime rendered multimedia art. Today most demos are coded in C or even C with some scripting engine, but back in the days it was pure 680×0 assembler. The development took ages — Burning Chrome for example took me about 9 months of work which did not include the development of all effects included. All that work culminated in releasing the demo, usually at a demo party (My trusty old A1200 and me traveled quite some way across europe). If you were lucky, your demo really got one of the first places and you could return home with some fame *cough* and a bit of prize money.

Some time ago I started to capture some of my favourite works as videos to preserve them and finally got around to set them up here in my blog. Continue reading

Dojo Javascript Compression and IE conditional compilation

I often use the dojo javascript compressor system which is a very nice way to reduce the site of larger js libs. It uses the Rhino javascript interpreter to reduce the size of all local variables and removes all unessecary spaces and comments — but most importantly it keeps the external API of a javascript lib like it is.

A minor problem with that was that I like to use Internet Explorer specific conditional compilation to handle Internet Explorer’s non-standard js garbage. (I would really like to be able to fully ignore IE, but ignoring 70% of all Internet users is not really going to please my clients).

Since the compressor removes all comments from the js files it also removes conditional code sections. There are plans to make the compressor keep them but they’re postponed until at least dojo 0.4.

So for now I wrote myself a little bash script that replaces the conditional comments with javascript expressions that are not removed, compresses the js file and reinserts the conditional comments.

I have tested this only on linux but you should also be able to use it under OS-X or under cygwin for Windows.

Using this script

/* Javascript compression Test */
alert("Js compression test");

function foo(arg)
var local=arg;

/*@cc_on @*/
/*@if (@_jscript_version >= 5)

alert("You are using Internet Explorer 5+");

function bar(arg)
var localIE=arg;

@end @*/

is compressed to

alert("Js compression test");
function foo(_1){
var _2=_1;
/*@cc_on @*/
/*@if (@_jscript_version >= 5)
alert("You are using Internet Explorer 5+");
function bar(_3){
var _4=_3;
@end @*/

That does not seem that much for this small example, but for larger libs the reduction is not that bad. The current version of my ff js lib e.g. compresses from 12005 bytes to 7644 bytes (36% reduction).

Update: corrected custom_rhino.jar URL 

Storing hierarchical data in a database

When looking for a good way to store nested comments in a SQL database I stumbled upon the explanation of an algorithm called “modified preorder tree traversal” algorithm [2]. Instead of storing a parent-child relationship into the database and having to do one SQL query for every node, it allows querying the whole comment tree (and subtrees) with a single query.

The basic idea is to walk along the outside of the tree hierarchy and to number the left and right side of every node along the way:

While this is rather unintuitive it allows to:

  • Get the sub tree of an node by selecting all nodes whose left value is between the left and the right value of the top node of the subtree
  • Get the path of a node by selecting all nodes whose left value is smaller than the left value of the node in question and whose right value is larger than its right value
  • Determine the number of children of a node by calculating:
    ( right value – left value -1 ) / 2

The disadvantage of this approach is that the addition of a single node leads to changes in all nodes to the “right” of it. After pondering the problem for a while I came up with a variant of the algorithm that gets rid of that. Instead of using simple consecutive numbers for the left and right values I wrote an algorithm which spreads all the left/right values over a fixed range of numbers. The top node starts with a fixed left and right value and children are inserted by splitting that interval into smaller sub-intervals. This makes it possible to not change the key values on inserting and do that insert with a single writing operation.


  1. Postgresql stored procedure implementing the keyspace variant
  2. Modified preorder tree traversal algorithm
    Another explanation of the modified tree traversal algorithm with code samples in PHP

© 2019 fforw.de

Theme by Anders NorénUp ↑