A lot of JavaScript programmers use an anonymous function at the top level, to establish a scope. This allows variables to be defined in a file (or module if your prefer), without adding anything to the global namespace.

The problem with this, however, it that it becomes awkward when you do need to add something to the global namespace.

Here’s a trick that solves this problem.

    (function()
    {
        var global = (function(){return this;}).call();
        global.Formula = function (){
            // body of function
        };
    })();

This code is equivalent to:

    var Formula;
    (function()
    {
        Formula = function (){
            // body of function
        };
    })();

Both forms have the same number of lines of code, but the first pulls ahead for each additional object added to the global namespace.  But there are other advantages.

• It is made explicit, that the assignment to Formula is being made in the global namespace.
• Suppose you decide that Formula and its companions should live in a different namespace.  In the first, simply search and replace on ‘global’ and replace the definition of global.
• In the first, we take care to explicitly obtain the object we are changing, namely the global object.
• According to Douglas Cockcroft, “JavaScript’s global object [...] is far and away the worst part of JavaScript’s many bad parts”. Writing as in the first example discourages and makes explicit the use of the global object.

JavaScript has a ‘new’ operator for creating objects. Each object in JavaScript has a hidden pointer to a prototype object, from which it inherits properties. This pointer is set when the object is created, and cannot be changed during the lifetime of the object.

When ‘new’ is used, an object is created that has other than the usual default Object prototype object.

From ‘new’ we can define a function create(proto) that returns an object whose prototype object is ‘proto’. (I first saw this in Douglas Cockcroft’s book JavaScript: The Good Parts, but he calls it ‘beget’.)

Conversely, from ‘create’ we can define a function, say ‘New’ that has the same functionality as the ‘new’ operator. (In JavaScript ‘new’ is a keyword, whose meaning can be changed.)

The ‘create’ operator is in some sense simpler than the ‘new’ operator, but each can be defined in terms of the other. According to Wikipedia, syntactic sugar “is syntax designed to make things easier to read or to express, while alternative ways of expressing them exist”.

I think ‘create’ is simpler to use and understand than ‘new’, and so I don’t regard it as syntactic sugar for the creation creation of objects.  The same Wikipedia term also suggests the term  syntactic saccharin for gratuitous syntax which does not actually make programming easier.  I consider ‘new’ to be syntactic saccharin.

Here’s an analogy (and I don’t know how useful it is). It’s about writing JavaScript for web pages.

A beetle, for example, has a hard external skeleton, to which everything else is attached. A cat, for example, has a hard internal skeleton, to which everything else is attached. A cat is soft outside (although with teeth and claws) while a beetle is soft inside.

So what’s this got to do with JavaScript and HTML? Well, a simple HTML page spruced up with some JavaScript for say form entry is a bit like a beetle, where the HTML is the hard external skeleton.

But a complex web page, constructed mostly from JavaScript and Ajax supplied data is something else. It’s too big and complex to be supported just by HTML and the DOM. It needs some sort of skeleton. And so perhaps should be built more like a cat.

This is not a new idea. The famous Model-View-Controller design pattern requires three independent but linked components. And to my way of thinking, the Model is like the skeleton.

Whether or not you like the analogy, you can ask this: Does my application have a major component that can function relying on HTML and the DOM? My view is that for complex things this is the way to go, rather than hanging everything on the DOM.

Here’s another analogy. A modern web framework, such as Django or Rails, has something like a skeleton, and then templates can be used to add presentational logic and preferences. This is so different from the old CGI-script way of doing these things.

With a modern web-framework, generating the HTML is an important but external task. The generated HTML is like the soft skin of an animal. (Yes, even the rhinoceros has soft skin, although not like a baby.) The web-framework helps provide a good part of the skeleton.

There’s a shift in attitudes and culture required to go from writing HTML web pages to writing a modern web application. Perhaps a similar shift is beginning to happen in the writing of the JavaScript side. The Google Web Toolkit is a good example of this culture shift.

I’m standing for the board of the TeX Users Group. You’re invited to make comments on my election statement below.

I work for the Open University (the UK’s leading provider of distance education) as a TeX expert for print media. I’m also halfway
through a two-year project on putting mathematics on web pages.

In 2006–7 I set up MathTran, which now provides typesetting of
TeX-notation formulas to images as a public web service, serving
about a million images a month.

MathTran shows the value of TeX as a web service, which I’d like to
extend to whole documents. Installing and configuring TeX can be
slow and difficult. Using TeX through a web browser will help
beginners.

Part of my math-on-web project is a page where students can
interactively create a TeX-notation formula, say for putting on a web
page or in a word-processor document.

I have a doctorate in Mathematics and although not my career I still
have research interests. I have been using TeX for over 20 years,
and joined TUG in 1989. For the past two years I’ve been Chair of the
UK TeX Users Group, and have recently been re-elected for another
two years.

The past three years have seen UK TUG come out of a long period of
inactivity and decline. The credit for this of course belongs to the
Committee and the members, and not simply myself. We’ve organised
three successful meetings, adopted a new constitution, and set up a
website with links to UK TeX resources.

As a board member I would bring to TUG a focus on a key core
community, namely those who write material with lots of mathematics.
I have a particular interest in providing help and support,
particularly through web pages.

TUG, by virtue of TeX being a typesetting program, rightly has a
focus on print media. But to flourish we must also use new media
effectively. The Open University faces the same challenge, and my
experience there will help TUG.

TUG has a special responsibility, to publicise TeX and related
fonts, programs, documentation and other resources.

I’d like TUG to offer more to institutional members. In particular,
we should help them share user support experience and resources.
Supporting TeX can be daunting without outside help.

When I joined TUG there were over 150 institutional members. There are
now just 27. The loss I feel the most is the Library of Congress.

The problem

JavaScript has objects and what is called prototypal inheritance, but it does not have built-in support for many features provided by other languages. In particular, it does not have built-in support for classes and instances. Nor does it have built-in support for methods of one class to call super-class methods.

Here is an example. Class C is a subclass of class B, and both have an init method. We would like the init method of Class C to be able to call the init method of class B. In other words, when writing init for class C, we wish to call the super-class init method. Note that class B might in fact be a subclass of class A, and that B might inherit init from A, and not have an init method of its own.

This post of focussed in the single topic of providing access to super-class. It does not for instance cover how to provide support for class hierarchies and how to manage instance creation.

Motivation

Over the past few days I’ve been trying to understand John Resig’s post on Simple JavaScript Inheritance, on both the technical and the practical levels. John’s goal was to extract the soul of the implementations of classical inheritance in base2 and Prototype, and to present them as a stand-alone package.

Well, I’ve not succeeded, but I do understand the problem better. In particular, I couldn’t get a clear understanding of what his _super method did. So to help me understand I set out to write my own. And this is what I came up with.

I hope in a later post to compare the two approaches. Be warned that this post is unavoidable quite technical, and that if you’re a JavaScript novice you’ll learn a lot if you manage to understand it all.

Setting up inheritance

First we have some code that sets up A, B and C, which are what we can think of as classes, and also c, which we can think of as an instance of C. (This way of thinking is not shared with the computer. So far as the program is concerned, the relationship between B and C is exactly the same as that between C and c. But to our mind one is subclass and the other is instance.)

var fromProto = function(proto){
    var f = function(){
        this.proto = proto;
    };
    f.prototype = proto;
    return new f();
};

// 'Classes':  A <- B <- C
var base = {};
var A = fromProto(base);
var B = fromProto(A);
var C = fromProto(B);

// Test object - 'Instance': C <- c.
var c = fromProto(C);

The function fromProto creates an object whose prototype object is ‘proto’. It also records that fact. (There are other, implicit, ways in which this fact may be recorded. But for clarity, here we will make it explicit.) I learnt about this way of doing things from Douglas Crockford’s book JavaScript: The Good Parts.

Setting up methods

So that we can test our implementation, we will create some methods. We will give A methods getA and setA that get and set an ‘a’ attribute on the object. Similarly, we will give B methods getB and setB (that this time get and set a ‘b’ attribute). Once we have done this, c.getA for example will access the A method, because of the usual operation of prototypal inheritance.

To that we really are fetching super-class methods, we will add to C spoiler methods getA, setA, getB and setB. When called, these spoiler will raise an error. We will also add spoilers getB and setB to A.

To shorten and clarify the code, we introduce a couple of factory functions, for creating get and set methods.

var _get = function(key){
    return function(){
        return this[key];
    };
};

var _set = function(key){
    return function(value){
        this[key] = value;
    };
};

And now we can very simple set up the access methods and the spoilers.

A.getA = _get('a');
A.setA = _set('a');

B.getB = _get('b');
B.setB = _set('b');

// Spoilers - will not be called.
C.getA = C.setA =
    C.getB = C.setA =
    A.getB = A.setB =
    function(){
        ddt();
    };

Low-level access to super-class methods

Here we use only JavaScript primitives to access super-class methods. We don’t define and use functions of our own (we’ll do that later). In fact, the code below tells up what primitive commands the functions we define must call.

We wish to call the method A.getA, but with the special this object being the object c. If it were not for C have the spoiler method C.getA, we could write c.getA() to call A.getA with this being c. But the spoiler is there, so we have to do something else.

JavaScript has apply and call methods precisely for dealing with this problem. They allow us to specify the object that is to be bound to this during the method call. More exactly (and this has to be fully understood to follow the rest of this post) both of the function calls below:

    fn.apply(that, [arg0, arg1, arg2, ...])
    fn.call(that, arg0, arg1, arg2, ...)

are equivalent to

    fn(arg0, arg1, arg2, ...)

except that in this function call this is bound to the value of that.

This, apply and call are exactly what we want. Moreover, JavaScript does not provide any other method for doing this. We are obliged to use apply or call. We have not choice here, except which to use. (We’ll have more choice later, in how to package our call in functions of our own devising.)

Using call to access super-class methods

We can now write and run our first test function.

C.test1 = function(){

    // Understanding proto.
    C.proto === B || ddt();

    // Here's how to call set.
    C.proto.setA.call(this, 'a1');
    C.proto.setB.call(this, 'b1');

    // Check that set worked.
    this.a = 'a1' || ddt();
    this.b = 'b1' || ddt();

    // Call get, and check that it worked.
    C.proto.getA.call(this) === 'a1' || ddt();
    C.proto.getB.call(this) === 'b1' || ddt();
};

c.test1();

The code above runs without error. Note that we use C.proto to access the inheritance chain, rather than use our knowledge that C.proto is in fact B.

Why we need a sweeter syntax

The above code works, and is perhaps optimal for execution time. (If as is likely we knew that C.proto.getA was not going to change, we could do this calculation outside the method body and use a cached result to make it run quicker.)

But it far from optimal for programmer productivity. There are several aspects to this:

• It is not immediately obvious that we are calling a super-class method.
• The code is tricky to write.
• The code depends on an implementation detail – the use of proto to hold the prototypal object.
• The code contains a gotcha – omit call and it silently fails.

Some more on the gotcha. The line of code

    C.proto.setA(this, 'a1');    // Gotcha! You forgot the call!

first resolves C.proto to B, and then B.setA to the function A.setA. It then calls A.setA with arguments the value of this (which is the test object c) and the string ‘a1′. And now for the gotcha. In this function call, this is bound to the previous value of this (and the argument ‘a1′ is ignored). Therefore, in this particular case, the above line of code has the same effect as

    B.a = c;

which is not at all what is wanted.

We don’t want traps like this lying so close to the code we are writing. We want to focus, so to speak, on the road rather than the potholes. We need a sweeter syntax. (And should performance be an issue, we can later unwind the sweeter syntax into the primitive operations presented earlier.)

A sweeter syntax

Here we have some choices. We wish to sweeten the previous syntax. Let’s recall what we have

    C.proto.setA.call(this, 'a1');

Now we have to choose. My choice is

    sup(C, 'setA')(this, 'a2');

Notice that sup(C, ’setA’) is a drop-in replacement for C.proto.setA.call. This is why I like it. (I chose ’sup’ because we can’t use ’super’, which is a reserved word in JavaScript. It is one of the many reserved words in JavaScript, that are not actually used in the language.)

Although this is my present choice, I hope that I’m open to persuasion and learning from experience. I also believe that going along with the majority is sometimes (not always) the best thing for the community. So if the choice of syntax matters to you, please speak up.

High-level access to super-class methods

We’ll now rewrite the low-level test using the sweeter syntax. Here it is:

C.test2 = function(){

    // Here's how to call set.
    sup(C, 'setA')(this, 'a2');
    sup(C, 'setB')(this, 'b2');

    // Check that set worked.
    this.a === 'a2' || ddt();
    this.b === 'b2' || ddt();

    // Call get, and check that it worked.
    sup(C, 'getA')(this) === 'a2' || ddt();
    sup(C, 'getB')(this) === 'b2' || ddt();
};

Before we can run this test, we need to implement the ’sup’ function.

Implementation of sup

Recall that

    sup(C, 'setA')(this, 'a2');

is to be equivalent to

    C.proto.setA.call(this, 'a1');

Here’s the definition of sup. I find it the hardest piece of code to understand in this post. I think you have to see it first, and then work through understanding it.

var sup = function(klass, name){
    return function(){
        var fn = klass.proto[name];
        return Function.call.apply(fn, arguments);
    };
};

So let’s go through it, step by step.

1. The sup function returns a function. This is good. We will be calling this function with, say, c and ‘a1′ as arguments. For now, let’s call this function supSetA.
2. The function supSetA has set up a closure (we won’t explain here what that is) and as a result klass and name have within supSetA the values that were originally supplied. (By the way, ‘class’ a reserved word in JavaScript that is not used, just like ’super’. So we use ‘klass’ instead.)
3. Executing supSetA sets fn to the function A.setA, exactly as before. (We don’t move that calculation outside the definition of the returned function. Our focus is on programmer productivity, and we can’t be sure that we’re able to safely cache this value.)
4. We now execute Function.call.apply(fn, arguments), which is so complicated we’ll give its explanation all by itself.

The Function.call.apply pattern

I’m fairly confident that I’m the first person to publish code that uses this pattern. (To check, I did this Internet search and also this one for the string ‘Function.call.apply’. At the time of writing, they produced 19 hits, none of which coincide with our use.) So if you’re an early reader, you might be the second person on earth to know about this pattern. Don’t be surprised if takes you a little while – it took me about an hour!

Let’s unpack the pattern. We have

    Function.call.apply(fn, arguments);

Here goes:

1. Recall that myfunc.apply(obj, [arg1, arg2, arg3, ...) will execute myfunc(arg1, arg2, arg3, ...), but with this set equal to obj.
2. In our case we have
   1. myfunc is call.
   2. obj is the function A.setA.
   3. arguments is [c, 'a2'].
3. So now we have call(c, ‘a2′), but with this set equal to C.proto.setA (which is equal to A.setA).
4. Recall that previously we used the low-level code C.proto.setA.call(this, ‘a2′) where this is c.
5. Now for the hard bit. In (4), we are running call(c, ‘a2′), but with this set equal to C.proto.setA. (Please take some time to think about this. It follows from the rules as to how this is determined.)
6. Now for the easy bit. Steps 3 and 5 are identical, and so give the same result. This is what we wanted to see.

Conclusion

This has been a long and technically demanding post. As stated earlier, I hop to discuss the relation to other approached in another post.

I’m optimistic that most of the ideas in this post will make their way into at least one future JavaScript classical inheritance framework.

At the same time, I’m bearing in mind Douglas Cockcroft’s warning:

I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.

My view (based on about 18 months experience of JavaScript) is that there’s room for improvement in the way in which we handle inheritance. I learned a lot about JavaScript when authoring this post, and I hope that it will also help others.

The Problem

Suppose we want to count the words in a document, or the identifiers in a computer program. We’ll need to keep a dictionary (aka hash or mapping) whose keys are the words and whose values are their frequencies. When we come across a new word (or identifier) we add it to the dictionary as a key, with value equal to one. When we meet a word already in the dictionary, we increase the value by one.

The starting point, of course, is an empty dictionary (or mapping or hash or whatever you want to call it). In JavaScript creating one of these requires some thought, and seems not to have been done before. Here’s the problem. In JavaScript we have to store the data (key-value pairs) in an object, and every object comes with some builtin methods. Here’s some command-line JavaScript:

js> data = {};  // Create empty data object, we hope.
js> data.foo === undefined; // true
js> data['foo'] === undefined;  // true
js> data['constructor'] === undefined; // false - not what we want.

Explanation

JavaScript has what is called prototypical inheritance. This means that every JavaScript object has a prototype object, and that the original object inherits from the prototype object. Let’s call them obj and prot respectively. If we look up ‘obj.foo’ and this fails, then we try ‘prot.foo’ and if found use that instead. And if ‘prot.foo’ fails we look up ‘protprot.foo’ (where ‘protprot’ is the prototype object of ‘prot’) and so on, until we get to the end of the prototype chain.

As it happens, Object.prototype is the prototype object for data, and Object.prototype has a ‘constructor’ attribute. This is why data has a ‘constructor’ entry. It has some others, such as a ‘toString’ method.

Solution

A probably dangerous solution is to change Object.prototype, because this would change the behaviour of all objects, and would probably break a lot of scripts. Perhaps better is to create a new sort of object, which masks the unwelcome builtin attributes. Here’s the code to do this.

var Data = function(){};

Data.prototype = {
    // Note: 'for in' does not pick up builtin properties.
    'constructor': undefined,
    'hasOwnProperty': undefined,
    'isPrototypeof': undefined,
    'propertyisEnumerable': undefined,
    'toLocaleString': undefined,
    'toString': undefined,
    'valueOf': undefined
};

var data = new Data();
data.constructor == undefined;  // Is now true.

Discussion

First, here’s why I said earlier that the solution appears to be new. Douglas Cockcroft, in his new book JavaScript: The Good Parts, writes (p23) that there are two solutions to dealing with these undesired properties. The solutions he gives are to use the typeof operator or the hasOwnProperty method. He doesn’t mention the masking solution above. Douglas is very knowledgeable about JavaScript, and so that’s why I think this method is new. If you know better, please let me know.

Now for an unwelcome but unavoidable side effect. It your program tries to convert data into a string, it will fail. This is because data does not have a toString method. This is the unwelcome side effect. It is unavoidable, because if data did have a toString method, then it would show up, and data would not be initially empty. The same goes, of course, for the other Object methods we’ve masked, such as constructor.

You might think not being able to turn data into a string is a problem. It shouldn’t be. The keys and values of data can still be turned into strings. If you must turn data into a string, the code

Object.toString.apply(data)

will do this, using the usual method.

Finally, even if your code relies on turning data into a string, you may be better off using the Data approach. This is because when you add the key ‘toString’ to data you’ll immediately loose the ability to turn data into a string (unless toString has exactly the right value). If you use the Data approach, your data will start with the Object methods being masked, and so you’ll have to deal with it up front. If you use one of the other two approaches, the Object methods will be masked later, when the program is given unusual input.

Learning from mistakes

This post is about my experience of learning jQuery. I’m developing some JavaScript for use with MathTran, and from past experience I know that I need a library. Elsewhere I explain why I’ve chosen jQuery. On Friday I started learning jQuery, mostly from the two Packt books, and yesterday and today (Saturday and Sunday) I’ve started with some coding.

I’m fairly new to JavaScript programming, and it’s easy for me to trip up on some of the language features. For example, it’s my Python habit to write ’self’ when I really should be saying ‘this’. I addition, I’m not used to the widespread dynamic creation of functions, to be attached to DOM elements to handle events. So in addition to learning how to think jQuery, I’ve also been learning how to think JavaScript and DOM.

My first mistake: changing the DOM

Each formula can usefully be displayed in one of three ways

• TeX notation only
• Image only
• Both TeX and image

I wanted a way to toggle all the math objects between TeX-only and image-only. And I had not even thought that one might want to see both at the same time.

The solution that first came to my mind, and which I started to code, was keep a list of all math-content nodes, and to change each of them in the DOM to achieve the toggle. In other words, the JavaScript would traverse the math nodes, replacing certain image nodes with TeX notation spans, and vice versa. And to achieve performance I would keep a list of all math-content nodes. I even managed to half-persuade myself that this might be a good idea.

Well, I was wrong. Reading the Learning jQuery book, I came to appreciate the value of changing the class of an object (such as the document body) in order to change the appearance of the content of the object. So I came to realise that I could keep both the TeX-notation spans and the rendered images in the DOM, and switch the display on and off by changing some classes on the document body (and some fairly trivial CSS also). From here it’s pretty easy to see that I could also display both at once if I want to.

Summary Try to avoid making changes to the DOM. If something is temporarily not needed, leave it in the DOM, but hide it. Changing a few classes (which is a small change to the DOM) is better than changing lots of nodes in the DOM. Yes, the work of finding and changing the display of all the mathematics nodes has to be done when the user preference changes, but why not let the browser do that work. Simply change a class or two and let the browser do the work.

My second mistake: not being ‘HTML creative’

One of the things I know I want to do is to transform certain documents. I wanted the author of the HTML page to supply only the ALT text for certain images, and the JavaScript would provide the image SRC, which would be a URL pointing to the public MathTran server.

I was thinking of this as being a matter of changing the DOM. Something like

1. Compute and add a SRC attribute to the image node.
2. Wrap the node in a span.
3. Add a child to the span (a sibling of the image) for the TeX source.
4. Set some classes.

I wrote code that did this as a sequence of DOM manipulations. Later, I realised I would need the same code when I was adding completely new mathematical images to the document. I’m also coming round to realising that using the browser to create DOM nodes from a string can be an efficient route, both in terms of programmer effort and browser resources.

So I found myself writing a function that would take a template such as

<span class=mathtran>
<span class=mathtran-tex></span>
<img class=mathtran-img />
</span>

and then add the TeX-related objects to the resulting object. In other words, instead of doing a sequence of DOM manipulations, simply create the DOM node from an HTML template.

Summary Use HTML as a template when creating DOM nodes, rather than doing everything with DOM manipulators. Use the manipulators only to change attributes and simple text content.

My third mistake: being different

Users of jQuery, after time, build up expectations about how to do things. The library provides standard tools for doing common tasks, and they have a consistent API. There’s a jQuery way of doing things, that I am beginning to learn.

With jQuery one writes $('.simple') to select all nodes in the document that have class ’simple’. The plugin architecture of jQuery is one of its strengths, and so it makes sens for me to write a MathTran plugin for jQuery. Once one has this, one would expect to write $('.mathtran') to pick up all the MathTran nodes in the document. In other words, the standard thought patterns of jQuery, which seem to embody a great deal of wisdom and experience of JavaScript manipulation of the DOM, lead one to introduce and use a mathtran class in the CSS.

Put another way, much development follows the route

1. Set up some CSS (to control the display)
2. Use some selectors (to find suitable objects in the DOM)
3. Use jQuery to make minor changes to these objects

If I tried to follow this route, then it’s most likely that I would have avoided mistake one (making large changes in the DOM, rather than using the CSS to leverage some small changes).

Summary This is not a new mistake. It is another way of looking at the first mistake. But it points to the benefits of knowing and understanding why things are done and they are in jQuery, and then trying to do the same.

My first success: the .tex() method

Every MathTran node — selected by, of course, $('.mathtran') — will contain a TeX string. It’s fairly obvious that we want a method to get this string, and another to set it. Setting it, of course, should change both the content of the span that contains the TeX and also the SRC attribute of the image.

There’s already a similar method in jQuery, which is the html() method. You can read documentation for it here. Giving the tex() method a similar API makes life so much easier, both for the programmer of the MathTran plugin for jQuery and for the user.

My second success: the .mathtran() method

If only out of vanity, we’d like the mathtran plugin to provide a mathtran() method. It’s fairly clear that it should construct mathtran nodes, that can be placed in the document tree. A little thought tells us that is should be what in some languages is called a class method. Mathematics exists in two forms, inline and display. The typography is different in the two cases. For example, compare with . The first is good for paragraph text (where it is important that formulas not be too high) and the second works well in displays (which is used for important formulas, and where the width should not be too great). So it’s clear that the typographic style should be a parameter to the mathtran() method.

I’ve not sorted out the API for this method yet, but it’s beginning to take shape.

How to ‘toggle’ with three choices

This post started with the three ways of displaying mathematics — TeX notation only, image only, or both. I’d like to put a button on the page that ‘toggles’ between the three possibilities. Writing this in a way that works well with jQuery is my current challenge, and part of my JavaScript, DOM and jQuery learning curve. You can see my currrent attempt here.

Conclusion

It’s important to make mistakes, and it’s important to learn from them. This is an example of the dialog between theory and practice (and my habit is to favour theory). As for jQuery, it has a well thought out API (that’s theory) which I should use as templates and examples when coding the MathTran plugin for jQuery. I should learn to rely more on CSS, particuarly when it can leverage minor changes to the DOM.

One final point. I’ve found that jQuery favours a sort of declarative approach to programming (make a series of statements about the situation and leave the browser to follow the resulting rules) rather than the procedural approach (tell the browser, step by step) what it should do. This is another aspect of the CSS example I’ve discussed in this post.

This post is mainly for system administrators and developers who want to add mathematics capabilities to a blog or wiki that they host or develop. We hope that in a year or so some of the ideas we describe here will be available to ordinary users who have a blog, say on WordPress.

After an Introduction, we discuss Light-, Medium- and Heavy- weight installation of MathTran. Then we discuss how to print mathematics using MathTran. Finally, we revisit the examples in the introduction, and state conclusions.

Introduction

In fact, let’s start with Terry Tao’s blog, which is on WordPress. In case you didn’t know, Terry Tao is an eminent and talented young mathematician who is extremely web-savvy. He decided to move from a static web-site to a blog for his news and discussion articles about a year ago. Original he moved to blogspot, but then soon moved on to WordPress, because it gave better LaTeX support. Last month he told us that he has decided to publish a book version of his blog.

For me, Terry Tao’s blog provides a good example of where we are right now, and where we’d like to be. Of course, there are other examples. Most of us are not nearly as mathematical as Tao is. The many mathematics pages on Wikipedia provide another example. The Wikimedia foundation has recently announced a project to convert Wikipedia content to PDF. (The development of the software is being led by PediaPress.com, whose web-site is one of the case studies in The Django Book, which neatly ties in with another interest of mine.)

So this may be enough to set the stage. We’re interested in getting mathematics on blog, wikis, forums and other ‘Web2.0′ sites. We want good LaTeX support, good display, and the ability to go to PDF.

Lightweight installation

MathTran is a public web service, and so a lightweight installation can be made simple by putting some Javascript in the HTML header, and coding up the IMG elements on the page appropriately. All this is described on the MathTran home page (at present, it might get moved later).

Another intriguing form of installation is via a MathTran bookmarklet, which has been devised by my colleague Tim Hunt at The Open University. This allows MathTran to do it’s magic on content that has been marked up using TeX’s traditional $$ x^2+y^2=1$$ notation. This is a transformation controlled by the web-browser and its user. It does not require the server of the web page to do anything at all. To try it, install this bookmarklet in the way Tim described above and click on it. You will see the previous formula be replaced by it’s rendered TeX form. (The MathTran client Enso TeX Anywhere does something similar in many Windows documents.)

MathTran can provide lightweight installation because

• It is a high-performance web service (it runs TeX as a daemon, waiting and ready for the next request)
• It is a public web service
• It can provide its service via dynamic HTML

Any public high-performance dynamic HTML web service will support lightweight installation. One of the most widely deployed examples is the Google Ad Client, which adds advertising to many web pages (and provides revenue to the owner of the page).

Medium-weight installation

Now suppose you don’t want your users to get the mathematical images from the public MathTran server. Several good (and perhaps not so good) reasons for this are

• You don’t want to rely on a third party service.
• Your users are in a secure or mobile environment, and do not have direct contact with the Internet.
• You want goodies, such as baseline alignment of images, that at present require the page and the image to come from the same server.
• You want to write code that works as if you had your own MathTran server.
• You want a backup in case your own MathTran server (see below) goes down.
• You don’t want your users to know you’re using MathTran.

You can get most or all of this by setting up a transparent proxy server, complete with caching if you need it. None of this should be at all hard for a web-developer, and if you need and write one please do let us know so we can share it. Who knows, perhaps there’s one out there already.

[Some clever Javascript programming, together with serving JSON, allows baseline alignment even when the images come from somewhere else. But for now I encourage you to set up a transparent proxy if you can.]

Heavy-weight installation

This will be, as the name suggests, more work. For a start, you will need Linux or Unix because the MathTran server uses named pipes and sockets in a way that Windows does not support. I hope to discuss this further in another post.

Printing mathematics

Let’s suppose you want to produce a high-quality PDF file from a web page that contains MathTran mathematics (or at least mathematics that MathTran can handle).

Well, you’ll need something to handle the ordinary text, and if that something is TeX then you can probably just feed the TeX-encoded mathematics into it. But suppose your using some other tool, such as Apache’s FOP. MathTran generates bitmaps, so then can be included into the output by FOP. But we want high-quality output, and that means using outline fonts.

Each bitmap image served by MathTran contain invisible metadata, including the dvi output from TeX specific to that image. This dvi output, when combined with a suitable header, can be processed by dvips to produce EPS files, which FOP knows how to handle. An alternative route, which is more work but which probably produce better results, is to teach the PDF-writer used by FOP how to translate the dvi output into PDF directly.

Compared to writing a high-quality typesetting program such as TeX, writing software that translates TeX output to EPS or PDF or whatever is fairly simple (or so I believe, not having written either). Integrating MathTran into an open source PDF formatting program should not be so difficult, and would certainly be easier than writing an alternative to TeX.

Here is an example. After the EuroPython 2007 conference Dinu Gherman created a simple test script (lightweight application) that shows how to use MathTran with ReportLab (which has an open source version).

Conclusions

Both WordPress and Wikipedia use (La)TeX as their input syntax, and use TeX typesetting to generate mathematical images. TeX is the mathematics notation used by research mathematicians and physicists. MathTran makes TeX typesetting available as a public web service, which allows for lightweight installation in third party applications.

The present situation is not satisfactory – Terry Tao has to do manual conversion work to turn his blog into a book, and I expect that PediaPress will have to work hard to get mathematics working in their output. However, I hope that I have shown how MathTran both improves things where we are and is part of the path that takes us to where we want to be.

[Clearly, there's more to say than we've said here. Please leave comments and I'll write another post.]

Postscript

A Java client – 27 Feb 2008

Alex Clk has written a simple MathTran client in Java. To answer a couple of questions he asks in that post,

• To change the size of the image, use D=<n> in the query string, where <n> ranges from 1 to 10.
• The MathTran service has funding to August 2008, and is I expect that funding for 2009 will also be found.

Of course, the more useful and used it is, the easier it is to find funds.

IE has a bookmarklet length limit – 4 Mar 2008

Internet Explorer has a length limit on bookmarklets,  and Tim Hunt’s MathTran bookmarklet exceeds it.  With rewriting it can be cut down to fit, but I’ve not done that yet.  For more details see Browser Bugs on this page.

… but will they be happy together?

Microsoft loves Yahoo, but will they be happy together? To find out visit the LoveGraph page for this match.

LoveGraph uses a special algorithm to generate data about the potential of the match, which it then graphs. Do pay particular attention to the “Spheres of Interest Overlap” chart.

LoveGraph uses charts and graphs generated by Google Charts.

Some comparisons

Here are some more serious comments on Google and Microsoft, based on looking at a couple of web pages.

Google sell advertising on its search pages. It also sell advertising on other people’s pages. For example, the LoveGraph page mentioned above contains advertisements from Google. Both Google and the owners of LoveGraph get revenue if these advertisements are followed.

I’ve taken a brief usability look at the Microsoft home page. The graphic design is very impressive. At the top right there is a search gadget. Under the search box is a black down triangle next to the words ‘All Microsoft sites’. Do not press this triangle.

Oh, you did press it. You found that it ‘lifts up’ the menu, quite slowly. I timed it as 7 seconds. I don’t see the point of it, and it’s prominently on the home page. If you have lifted it up, do drop it down (another 7 seconds). Now press the ‘All Products’ link.

This brings up a screen-full of product images. Click on one of them, and then press the browser’s back button. And it does take you back, but to the Microsoft home page, not to the ‘All Products’ images you were previously at.

It is possible that Microsoft taking over Yahoo! will result in Yahoo being more of a rival to Google. But is also seems that the opposite is also quite possible.

Introduction

In my previous post I spoke about ReST. It’s not able to do what I want, which is a nuisance. But most of the post of about coding forms such as that on the MathTran home page using Django templates. In the course of the post I come to the conclusion that providing such forms is a matter just for the template, and has nothing much to do with the view! Finally, I make some remarks about AJAX, which is used (along with some rather improper dynamic HTML) in the present implementation.

Some problems with ReST

I’m now using ReST to author content for the website, and I’m finding it awkward. I quite like to put a link to be followed at the end of a sentence. Something like: Instructions on how to do learn TeX are here. (This link is broken at the time of writing.) However, ReST does not allow me to use ‘here’ twice in the same page, but pointing to different web pages. I find that this cramps my style, and in time there will be an example here.

Here’s another problem. The new home page will have a two-column layout, with main content on the left, and news on the right. I will, of course, use CSS to do the styling. And so I have to create two content DIV’s in the body. I can do this with ReST by having separate pages for the main content and the news, and this might be the best thing to do, but I don’t want to be forced into doing that by the architecture of ReST.

Finally, on the MathTran home page there is a form, that allows users to experiment with TeX. I don’t want to hardcode this form into the ReST source for the home page, and in fact I can’t, because I’ll need Django to put some results in under the form. And so it looks as if I’ll be forced into some appalling hack, such as putting a special string such as {{ my_form }} in the ReST source, which Django can then replace by the form. In short, a tiny templating language, processing the output of ReST.

I decided to switch from authoring in HTML because it is more work than it should be. But it seems that ReST can also produce additional work.

CSS and ReST

I’m going to use the CSS float: right style to get the two-column layout, and that requires the sidebar DIV to appear before the content DIV in the HTML. This might be a design fault in HTML/CSS, but I don’t think so. In any case, this is another example of how ReST is not fitting in well with other parts of the system. In my previous post I explained how I was having to do a hack to get the title to come out right. That said, I’m pleased that I’m using CSS, and seem to be getting to grips with the separation of content and style. I’m using Simon Collison’s beginner’s book as a reference.

The TeX data entry form

The present and new MathTran home pages will have a TeX data entry form, that allows the user to experiment with MathTran. This form, perhaps with variation, will be used elsewhere on the new site. It is an important component, and it’s implementation will make more use of the framework Django provides.

On the current site the form was written using JavaScript plus dynamic HTML, and prior to that we used a CGI script. The nice thing about the JavaScript approach, besides the nice user interface is provided, is that it allowed the form to be reused across the site without copying large chunks of code.

But some users might not be able to use JavaScript, or might for good reasons prefer not to use it. I’m beginning to value more the approach, that the site should be made accessible first, and then JavaScript can be used to enhance functionality. Not using JavaScript makes the site easier to test. And now that I’m using Django with its template language, the form should be easy to reuse.

The challenge here is to refactor the existing functionality so that business logic belongs to the view, presentation belongs to the template, style belongs to the CSS style sheet, and there are sufficient hooks to allow JavaScript and dynamic HTML to replace the logic in the view.

Ajax and Django forms

It’s now Sunday 3rd February, and I’m going to summarise the progress I’ve made. First, and this is important, I now understand the problem. It is this. In the current MathTran website pages some pages contain ‘user feedback’ data entry forms, that are created using JavaScript and function using some Ajax (to get the TeX log and the depth of the image). I don’t want to rely on JavaScript in this way, because it is repeating all the problems of Dynamic HTML of a few years back, as described in Chris Heilmann’s book, which I am using as guidance for good practice. I would like to provide the existing functionality on the new site without using JavaScript, and to enhance the interface by using JavaScript, if JavaScript is available.

So that is is the description of the problem. A bit of thinking tells us why that is a problem. Django has a View + Template architecture (the Model is not used here). But the DHTML approach so to speak promotes ordinary markup into interactive elements. And so to achieve similar functionality for the author of the web page or Django template the View is not involved either. These forms provide what I have called user feedback or more specifically the opportunity to experiment with TeX and some examples. They are a matter for the author of the template/page, not the programmer of the view. In particular, they should be available on any template, just as H1 headings are available on a view.

This brings me to the thing I liked about the DHMTL approach I followed, which is that the page author supplies minimal markup, and ‘the system’ provides the rest. The page author does not have to copy-and-paste boilerplate code. This is good, but using client-side JavaScript as the system that provides the rest is not a good idea. Except it’s not clear that for ordinary users (as opposed to power users such as Djangonauts) there is an alternative to coding in ordinary HTML.

I explored the problem without properly understanding it (and with gaps in my Django knowledge), and this turned out to be a good thing to do. First of all, I coded one of these forms using the View-Template architecture. I then realised that the Template shouldn’t really be tied to the view in this way. This was particularly acute when there were to be two, three or more of these forms on a template.

Using a working example

At this point I had a working example, so I knew it could be done. Also, the example provided a helpful framework for further exploration. So the thing to do was to do everything in the Template. (I could have deduced this from an abstract analysis of the problem, but it was good to get the experience into my coding fingers, and to have a working example.) So now I was casting about, without any other route, for a way to do the form using the Template only.

At this point I recalled that a well-written template does not change any data. This is part of the design philosophy of Django templates. In Chapter 4 of The Django Book we read A template cannot set a variable or change the value of a variable and that custom template tags can be written that do allow this. So that is what I was forced into doing, by the in my view quite reasonable requirements. By the way, being trained as a mathematician, I’m quite fond of problems that have exactly one solution. In mathematics it’s often easier to find something, if you know there is only one of them to be found. So here I actually liked the way the logic of the situation forced me into a particular solution, and I also liked the solution that so appeared.

So I sat down, motivated, to write a custom template tag that did what I want, and I had something working by the end of the day. It’s not ready to post anywhere yet, but I can show you how a preliminary form of the template interface.

<form>
{% mathtran wobble %}{# Assigns a value to the variable wobble #}
<p>TeX input: {{wobble.elt}}</p>
<input type="text" name="wobble" size="50" value="{{wobble.value}}"/>
<input type="hidden" name="old_wobble" value="{{wobble.old_value}}"/>
<input type="submit" name="set_wobble" value="Try it"/>
<p>TeX output: {{wobble.img}}</p>
<p>TeX errors: {{wobble.log}}</p>

This, of course, contains a large amount of boilerplate code that should be incorporated into the behaviour and properties of the mathtran tag.

Conclusion

Coding these forms properly is more work that I thought at first, particularly if I’m to do it properly. But the payoff is likely to be code that can be reused by any Django site that wants to use the MathTran service. Finally, there is a Django wiki page on AJAX which has some useful links.