mFabrik - web and mobile development » javascript

domgen – Creating HTML with Javascript without DOM API

Jussi Toivola — Thu, 02 Sep 2010 12:43:41 +0000

Tired of using Javascript DOM API for generating HTML dynamically? Meet domgen. domgen is a tool for easy dynamic content generation via Javascript. It generates DOM elements from dictionary specification similar to HTML and eliminates the need for cumbersome DOM Javascript API.

domgen uses a simple specification to generate the HTML. In some cases it’s more reliable to use DOM API to generate HTML instead of using innerHTML. We have had problems especially with iPhone when using innerHTML.
See for example http://pastebin.com/LLk3J0iH or google “iPhone innerHTML” for more info. In fact, innerHTML is not even part of the HTML standard even though it exists on every browser.

So if you want to add dynamic HTML properly, you should use the Javascript DOM API. Consider the following short HTML where the contents inside body had to be generated:


    my div

Using Javascript DOM API:

// Get the body tag
var body = document.getElementsByTagName("body")[0];
// Create 'div' element
var mydiv = document.createElement("div");
mydiv.setAttribute("id", "mydiv");
mydiv.innerText = "my div";
// Attach the div to body
body.appendChild(mydiv);

And using domgen:

var spec = [
    'div',
    {
        id : 'mydiv',
        _innerText : 'my div'
    }
];
domgen.generate( domgen.get("body")[0], spec);
// or with jQuery
domgen.generate( $("body")[0], spec);

To me, domgen seems a lot easier to read and work with. Get code and more examples here: https://bitbucket.org/mfabrik/domgen

To gzip or not to gzip CSS and Javascript?

Mikko Ohtamaa — Mon, 12 Apr 2010 10:38:14 +0000

Dear Lazyweb,

Is it wise to gzip static resources (javascript and CSS) before sending them to client?

The opinion of Internet seems to be divided

GZip decompression takes too much time at the client end and thus it is not wise (latency at the clients end)
Bandwidth save is enough to counter the decompression latency

So if we put this to context of

Compressed and merged CSS and Javascript files of Plone
Assuming the users are using the state of the art browsers: Safari 4, Chrome, Firefox 3.6 and IE8
Connections are faster than 384 Kbit/s

…and forget…

Recompressing images (GIF, PNG and JPEG) using GZip as there is no notable save

should I enable GZip compression on the front-end server (Apache) with disk cache enabled?

Of course, I could do testing and timing myself, but I’ll simply ask for your experiences first before investing few hours for this. Also, hints how to measure how fast GZip decompression is, are welcome.

Thank you.

Read our blog Subscribe mFabrik blog in a reader Follow us on Twitter Mikko Ohtamaa on LinkedIn

Now hiring (Developer, Helsinki)

veikko — Mon, 29 Mar 2010 09:14:31 +0000

We are looking for a new developer to join our production team in Helsinki, Finland. Check out the details at our web site:

http://mfabrik.com/about-us/jobs/developer-helsinki

Cross-platform mobile application development and payments

Mikko Ohtamaa — Wed, 30 Sep 2009 09:55:30 +0000

We have been piloting multi-platform mobile application development and payments in few client projects. Target platforms usually include iPhone, Android, Blackberry and Nokia Series 60. Also there are two notable usual cases which need to be specially handled

Image uploads
Payments for subscribed content

Sounds easy, right? Well it isn’t… Below are some notes for our due diligence work which you fellow developers might find interesting.

SDKs

Mobile phone vendors are jealously and don’t want to co-operate with each other. Building application which works in all handsets is major headache.

We found some reasonable candidates for cross-platform mobile development doing HTML and Javascript. HTML and Javascript pages are converted to native application using a wrapper technology (a.k.a. appaccelerator). Doing Flash Lite or Java ME can be pretty much forgotten nowadays as they won’t run on the most hyped platform, iPhone. Flash Lite has poor support for anything except content authoring due to primitive and limited APIs. Java ME provides horrible user experience.

(X)HTML is the only common language spoken by mobile phones. Thus, there has been a rise of “appaccelerators”, technologies which allow to create mobile applications with HTML(5) and Javascript.

Phonegap: iPhone, Android, Blackberry and possibly S60 in the future. Pluses: BSD license, very active community. Minuses: bad documentation, difficult deployment process.
Titanium: iPhone, Android. Pluses: Professional, Apache license. Minuses: Too tightly coupled with Appacclerator Inc. company.
Rhomobile: iPhone, Android, Blackberry, S60, Windows Mobile. Pluses: Professional, tries to build open source community, the widest platform support. Minuses: Dual licensing and tightly coupled with Rhomobile Inc.
Nokia Web-runtime: Nokia S60 and some other Symbian based phones. Pluses: Professional, good documentation. Minuses: Not open source, impossible to extend, Nokia has little interest to make this cross-platform, Nokia doesn’t like updating old models and web-runtime is useable only in the latest S60 5th edition models.
Palm Pre supports web applications natively. However Palm Pre application business is still taking a shape.

All these wrap the browser component (WebKit) and provide some extra Javascript APIs when your web pages as executed under the application mode.

Locationing
Contacts
SMS
Client-side database
and so on…

Rhomobile has little different use cases from the rest of the bunch as it provides client-side programming using Ruby and less focuses on Javascript/web applications.

Payments and in-application purchases

There are four major way to do mobile payments “inside” the application for bought content and subscriptions. The price tag on the application itself is left out on this discussion as the application stores themselves take care of it.

Credit card
SMS
App Store payment (thus far Apple only)
Direct operator payments – you have a service provider (Bango) which can directly charge items to the operator phone bill based on handset identification.

App Store payment is the most attractive as it provides the best end user experience. It allows you to use App Store payment mechanism inside the application. It is safe and no need to hassle with external payment providers. However, App Store payment can be used only for content consumed directly inside the application. You cannot use it e.g. for ordering a pizza. I think this might be related to recent EU legislation forbidding SMS payments for services not consumed in the phone itself.

SMS payment is ok for little payments. Operators take big cut of the revenue, generally 30% – 70% depending on the country. Short code fees usually start from 500€ set-up fee + 500€ / month. SMS cannot be often send as a background, but the user is presented the normal SMS editor which reduces the user experience somehow.

For credit card payments there exists several providers. Credit card has the cheapest entry fees, but the downside is that the user needs to have the credit card. This excludes teenager audience.

Direct operator payments are not very well supported yet globally. Most western operators support them. The operator also takes a big share and the fixed fee is pretty high.

My favorite payment provider thus far is Bango which provides credit card payment starting 9€ / mo. and scales up to worldwide SMS payments which cost few grannies per month.

In most cases, the payment experience will not be smooth. You need to open the phone main browser on the payment provider page to do the payment. This usually will close your own application. Rarely you can do the payment inside the application and support multiple platforms. After doing the payment most platforms allow you to close the browse and reopen your application using a special URL handler.

Wikipedia mobile payments page is also useful.

Image upload

won’t work on iPhone and some other platforms as those don’t have user browsable file system. Also the file dialog usually doens’t have image preview making it useless.

Phonegap has a branch which supports images picking using iPhone’s own gallery browser.

In any case, there is not yet cross-platform solution for this.

Future prospects

In some time-frame we will get rid of the need to wrap HTML applications natively as the web browser applications will support all HTML5 features without extensions and probably have some proprietary extensions for mobile specific features like SMS. We already have had some taste for this:

The first taste of this is Mozilla’s Fennec mobile browser which has locationing support.
iPhone’s Safari already supports client-side storage and CSS3.
All phones have support for dial-in links. The format of the link may vary. DeviceAtlas is good place to hunt for this information.
Nokia browser supports send SMS links
Nokia browser supports downloadable map markers (to the map application of the phone itself)

MooTools setOptions() nullifies object references

Tuukka Mustonen — Tue, 19 Aug 2008 00:21:08 +0000

I bumped up into a problem where the object references where resolved as object copies when I passed them to class instances. That might sound easy to resolve, but unfortunately I was already deep in code and it was difficult to see this. Therefore, here’s a little explanation for those who are facing the same frustrating issue.

Say, you have variable ‘a’ and you want to pass it to a MooTools class B instance during creation. In the easiest case you’d use new B({ myReference: a}) and trust on MooTools’ Class.setOptions() to minify the need of code lines. This is what you should do… well at least that’s what I did and in this case it was a mistake.

It turns out that Class.setOptions() merges it’s arguments to this.options and then takes copy of them via $merge(). That means that any variable references you pass to setOptions() will get copied to this.options and.. well, that’s it. See lines 1170-1173 in uncompressed version of MooTools 1.2:

var Options = new Class({
    setOptions: function(){
        this.options = $merge.run([this.options].extend(arguments));

That effectively nullifies the benefits of Class.setOptions() if you want to pass in variable references..

Here’s a longer example to clarify (use Firebug):

  // The most basic MooTools class that implements options
  // ref is a variable meant for pointing at given object
  // (won't do that, however)
  var B = new Class({
    Implements: Options,
    options: {
      ref: null
    },
    initialize: function(options) {
      this.setOptions(options);
    }
  });

  // Ok let's create an instance that we can pass to B
  // It's similar with all sorts of variables
  var A = new Class({
    initialize: function() {
      this.somevar = 'untouched';
    }
  });
  var a = new A();

  // Create an instance of B and give it somevar as reference
  var b = new B({ ref: a });

  // prints out "untouched" as should
  console.log(b.options.ref.somevar);

  // Let's change the variable (direct access, bad)
  a.somevar = "changed";

  // b's reference should still point to a, right?
  // In that case the following should print "changed",
  // but because our reference object was copied instead
  // of retaining reference to it, we just get "untouched"
  console.log(b.options.ref.somevar);

I don’t know why MooTools wants to make a copy of arguments in setOptions() – propably for performance reasons.

Catching silent Javascript exceptions with a function decorator

Mikko Ohtamaa — Mon, 18 Aug 2008 22:08:59 +0000

The one utterly annoying thing with the otherwise excellent Firefox/Firebug combo is that some exceptions are let silently through without being end up to be visible in the Firebug console. This makes debugging very difficult, unless you are aware of the phenomenon. I am not sure whether this is caused by some internal Firefox logic flow, since IE + Visual Web Developer doesn’t seem to be affected by this.

Since this problem pops up constantly, I decided to create an easy way to deal with the situation. I decorate all functions which made have silent exceptions (e.g. one called from document load event) with a custom logger function which will first log the exception and then rethrow it.

Thus instead of writing (JQuery example)

myfunction() {
    // crash here
    var i = foobar; // missing variable foobar
}

$(document).ready(myfunction);

write

myfunction() {
    // crash here
    var i = foobar; // missing variable foobar
}

$document.ready(logExceptions(myFunction));

// myFunction can be bind to many events and exceptions are logged always
myfunction = logExceptions(function() {
  // crash here
    var i = foobar; // missing variable foobar
});

$document.ready(logExceptions(myFunction));

The Javascript code for the decorator:

/**
 * Enhancd Javascript logging and exception handler.
 *
 * Copyright 2008 Red Innovation Ltd.
 *
 * @author Mikko Ohtamaa
 * @license 3-clause BSD
 *
 */

// Browser specific logging output initialization
// Supports Firefox/Firebug. Other (Opera) can be hooked in here.
if(!console) {
	// Install dummy functions, so that logging does not break the code if Firebug is not present
    var console = {};
    console.log = function(msg) {};
    console.info = function(msg) {};
    console.warn = function(msg) {};
} else {
    // console.log provided by Firefox + Firebug
}

/**
 * Try print human digestable exception stack trace to Firebug console.
 *
 * http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Error
 *
 * @param e: Error
 */
function printStackTrace(e) {

	var msg = e.name + ":" + e.message;

	if (e.fileName) {
		msg += " at " + e.fileName + ":" + e.lineNumber;
	}
	console.log(msg);

	if (e.stack) {
		// Extract Firefox stack information. This tells how you ended up
		// to the exception in the first place. I didn't find
		// instructions how to parse this stuff.
		console.log(e.stack);
	}
}

/**
 * Decorate function so that exceptions falling through are printed always.
 *
 * Returns a decorated function which will be used instead of the normal function.
 * The decorated function has preplaced try ... catch block which will not let
 * through any exceptions silently or without logging. Even though there is an
 * exception it is normally throw upwards in the stack after logging.
 *
 * @param func: Javascript function reference
 */
function logExceptions(func) {

	var orignal = func;

	decorated = function() {
		try {
			orignal.apply(this, arguments);
		} catch(exception) {
			printStackTrace(exception);
			throw exception;
		}
	}

	return decorated;
}

Verifying Javascript files with JSLint from Eclipse IDE

Mikko Ohtamaa — Thu, 27 Mar 2008 13:10:08 +0000

With Web 2.0, Javascript has gained a great foothold in the web development. Javascript, which was originally indented to be few lines of interactivity here and there, is now used for full-blown UI frameworks like Ext JS and Dojo. Because its toy background, Javascript is not the easiest language to debug. Also, the lovely phenomenon known as browser wars has ensured that professional Javascript development is PITA due to browser incompatibilities – It seconds the Symbian C++ embedded programming if you know what I mean.

Javascript is executed run-time. Thus, any errors cannot be cached until the code is run. JSLint is a verifier tool which checks Javascript syntax offline. Of course, it cannot detect application logic errors, but it makes sure that you don’t have cross-browser compability problems in your Javascript syntax. Maybe the most famous of these problems is the extra comma before the list termination which is ok for Firefox, but kills the page on Internet Explorer.

Some argue that this does not really catch bugs and instead a comprehensive unit-test suite should be used. This might be a requirement for a platform level Javascript library code, but it is often an overkill for your little site with some flashy dialog windows.

Installing JSLint

JSLint itself is written in Javascript. So you need to offline Javascript interpreter to run it. On Linux there exists Rhino. On Ubuntu, Rhino package is broken. and you need to download the orignal Rhino JAR from here and copy it to /usr/share/java.

sudo apt-get install rhino # Note https://bugs.launchpad.net/ubuntu/+source/rhino/+bug/93885

Then get JSLint offline version from here.

Running JSLint straight from the Eclipse

We use JSEclipse plug-in in Eclipse for Javascript development. Thus, it is convenient to to execute JSLint directly from the Eclipse IDE.

Drag and drop jslint.js to your project/scripts folder in Eclipse.

Create a new External tool like in the example below.

Then you can run it by just clicking “run external tool” icon. Output comes to the console window.

Checking all Javascript files during unit test

verify_javascript.bash can be executed from shell and it checks all JS files in your project. This is a nice feature to integrate to your unit test cycle.

Example:

$ bash scripts/verify_javascript.bash source/server/media/jssource/server/media/js/jquery.js

Lint at line 11 character 30: Expected '{' and instead saw 'var'.

...