Publishing to a page’s wall

According to the Facebook documentation, we need to register an application in order to use it to publish messages to a page’s wall. The process is explained on that page, so this should be a good moment to read it.

The process could be summarized as follows:

1. Create an application.
2. Get the token for that application to manage the user’s pages (where the user is administrator of those pages).
3. Get the specific token for that application through the user to a precise page.

While it should have been worked as it is explained on the documentation, I was having the following error:

(#200) The user hasn’t authorized the application to perform this action

So… why? According to the documentation, manage_pages is the only permission required for an application to access a page, and everything seemed in order. Actually, it wasn’t. After some tests going back and forth and some googleing, I realized I didn’t have enough scope, and adding publish_stream and read_stream seemed to be a requirement for the application to actually write to page’s wall. In addition, offline_access would produce a token that does not expire.

Once this issue fixed, the following steps should lead to a successful publication in a page’s wall from an external script:

1. Register your application here.
2. Obtain access to manage pages from the authorized page administrator
   https://www.facebook.com/dialog/oauth?client_id=$id&client_secret=$secret&redirect_uri=$uri&scope=publish_stream,offline_access,read_stream,manage_pages&response_type=token
3. Get an access token to the precise page of that administrator
   https://graph.facebook.com/me/accounts?access_token=$all_apps_token
4. Now you should be able to publish to that page with this token through a POST call to
   https://graph.facebook.com/$page_id/feed

Here you are an example in PHP that uses this token to publish messages:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

class Facebook
{	    
    /**
     * @var The page id to edit
     */
    private $page_id = 'XXX';	
 
    /**
     * @var the page access token given to the application above
     */
    private $page_access_token = 'YYY';	
 
    /**
     * @var The back-end service for page's wall
     */
    private $post_url = '';
 
    /**
     * Constructor, sets the url's
     */
    public function Facebook()
    {
        $this->post_url = 'https://graph.facebook.com/'.$this->page_id.'/feed';
    }
 
    /**
     * Manages the POST message to post an update on a page wall
     * 
     * @param array $data
     * @return string the back-end response
     * @private
     */
    public function message($data)
    {   
        // need token
        $data['access_token'] = $this->page_access_token;
 
        // init
        $ch = curl_init();
 
        curl_setopt($ch, CURLOPT_URL, $this->post_url);
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
 
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
 
        // execute and close
        $return = curl_exec($ch);
        curl_close($ch);
 
        // end
        return $return;        
    }
}
 
$facebook = new Facebook();
 
$facebook->message(array( 'message'     => 'The status header', 
                          'link'        => 'http://theurltopoint.to', 
                          'picture'     => 'http://thepicturetoinclude.jpg',
                          'name'        => 'Name of the picture, shown just above it', 
                          'description' => 'Full description explaining whether the header or the picture' ) );

Publishing to an app’s wall

In some cases, we might want to publish to the application’s wall itself, so that there is no need to have a second application to publish to the first one’s wall.

According to some of the discussions on the matter that can be found on the internet, this should work by simply using $page_id as the target and the same $page_id to request the manage_pages permission.

In this case, we would follow the same process explained above, but slightly simplified:

1. Register your application here.
2. Obtain an access code for your application
   https://graph.facebook.com/oauth/access_token?type=client_cred&client_id=$id&client_secret=$secret
3. Now you should be able to publish to the application’s wall with the token obtained through a POST call to
   https://graph.facebook.com/$app_id/feed

However, Following the steps above, I obtained an error again:

{“error”:{“type”:”OAuthException”,”message”:”(#200) Posts where the actor is a page cannot also include a target_id”}}

Which was way confusing since there shouldn’t be any limitation according to Facebook’s documentation. After some searching and reading literature about (here and here), I discovered that publishing from an application to its own wall is doable, and in fact it works very well with the JS API provided by Facebook.

Then why the JS API would achieve the goal while its web service sister just throws a mystic error? It was quite obvious that they had to be using somewhat different service url’s… after inspecting the HTTP calls made by the JS API and was surprised to found that it is actually a GET (instead of POST call):

https://graph.facebook.com/$app_id/feed?access_token=$token&callback=FB.ApiServer._callbacks.$some_callback_id&message=Hello%2C%20World!&method=post&pretty=0&sdk=joey

I just had to test this new url with the parameters of my application, and this time it just worked as expected:

https://graph.facebook.com/$app_id/feed?access_token=$api_access_token&message=Hello%2C%20World!&method=post

This is the only solution I have found so far to be able to publish messages from PHP on behalf of an application itself. It is a bit awful, but I haven’t found any other way to make this work, and the documentation provided by Facebook seems like knocking on a wall.

Has anybody found any better solution for this problem? Comments are welcome!

Until Internet Explorer.

Let’s not talk about its mystic JavaScript errors, DOM random model interpretations and box model hacks. I had heard about the 32 @import CSS statements limit before (here, here and here), but what we were experiencing was different: beyond a given number of nested CSS imports, it seemed like stylesheets stopped being loaded. This was a big WTF the first time we spotted the problem, and blindly fixed it by adding twice the deeper @import sentences into the higher level CSS files. After all, it worked then.

But after a bad night of guilty conscience that issue came back to me, and I decided to do some tests on the issue so that some light be thrown on this dark matter. This was the plan: a simple HTML file with a number of divs (with a border and height definitions to make them visible by default), and a set of CSS files that where imported in waterfall mode, each one of them assigning the background color of one div according to its nesting level. The rupture point would be spotted where div’s started to look blank. Something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<html>
	<head>
		<link type="text/css" rel="stylesheet" href="style01.css" />
	</head>
	<style type="text/css">
		body div{
			height: 30px;
			margin: 5px;
			border: 1px solid #000;
		}
	</style>
	<body>
		<div class="style01"></div>
		<div class="style02"></div>
		<div class="style03"></div>
		<div class="style04"></div>
		<div class="style05"></div>
		<div class="style06"></div>
		<div class="style07"></div>
		<div class="style08"></div>
		<div class="style09"></div>
		<div class="style10"></div>
	</body>
</html>

The CSS files would look all like this one (style01.css):

1
2
3
4
5

@import url("style02.css");
 
.style01{
	background: #111;	
}

And so on (style02.css, etc):

1
2
3
4
5

@import url("style03.css");
 
.style02{
	background: #222;	
}

And up to 10 nested levels, in my test. What the result was? Every major modern browser (Firefox, Chrome, Opera, Safari) produced the expected result:

On the contrary, under Internet Explorer 8 and, moreover, 9, the result matched the little ‘panic moment’ we had when dealing with our nested collection of widgets:

Which actually confirmed that Internet Explorer limits nested @import CSS statements to three from the first linked external stylesheet. In the example, up to style04.css. In a production environment this is not a big deal since all CSS files are going to be packed into a single minified and compressed bundle, but it really can piss your day off in development environments should you not be aware of this behavior.

Once again, a reason to make me think of IE as a bad joke of a real browser.

Modularity

It may seem trivial for small-medium web sites and the 80% of the web interfaces on the net. However, this matter becomes crucial for medium-big applications with complex interfaces and functionality. A good application architecture consists also on a good modularity design:

• All functions related should become a module.
• Modules must have a low coupling (high isolation), so that if a bug occurs, it affects only one module and some neighbors at most.
• The interfaces between the modules should be as small as possible.
• The interchange of messages through these interfaces must be also minimized.

A good modular design produces an architecture than is extendable, maintainable, adaptable and reusable, thus allowing to reach further goals. A lock of modular design just produces a bunch of unsustainable “spaghetti code”, eventually.

Black boxes

Another concept on the line of thought of modular design is black boxes. Engineering likes black boxes, they are useful, modular, isolated, independent, and provide a smart set of independent pieces that abstract their internal logic from outside.

Basically, a black box is an element whose implementation is unknown to us, but which is well-documented and produces an expected output, given a known input. This implies also abstraction and encapsulation: no inner property should be accessed or changed from outside the box, nothing from other parts of the application should affect the internal structure or functionality, and an I/O interface should be created so that this black box is only used as it was designed to. It is not about “protecting” the classes from malicious uses. It is to avoid ourselves incorrectly using these classes when their implementation is no longer in mind after several months of their creation. It is easy to forget a tree on a big, big, forest.

The beauty of this approach is that test plans are easier to design, code is written faster and programmers can rely on every piece of the application doing exactly what it is meant to. Black boxes become the cornerstone on which big applications’ architecture must lean.

Documentation

I’ve heard a lot of excuses from all kind of developers not to write a proper documentation. I, too, have used it sometimes, in darker times when I was learning how things should be done. That’s why I spot them easily:

• Release dates are tight and I barely can finish functionality.
• The code is self-explanatory.
• I will write it when I’m finished with this.
• I just don’t have the time to write documentation.
• …

Unfortunately, I have to say there is no excuse not to write documentation; moreover, it should be done first, before start writing a line of code: comment out what the function you are coding is to do, add a few lines explaining the process to get it, and don’t hesitate to add as many side information as you want. I know that pride about ‘not writing silly comments every good programmer should not need to understand the code’, and it is wrong.

Programmers are not magicians, they don’t read minds! Everyone has different coding styles, skills and languages, and it is not obvious for one to understand what a piece of code should do, just reading the code. It may be clear what it does but that might be wrong and the source of a bug being tracked for hours.

Not only have I seen many people spend many ours of their valuable time tracking ‘esoteric’ bugs through unreadable, unbearable, non-documented code, I’ve lost myself months of my short life figuring out the architecture and purpose of entire applications just because the last programmer “didn’t have the time to write documentation”.

Can you imagine the loss for the company? Huge, indeed. Finally documentation has its toll paid back, one way or another. I’d rather like not to waste my time, don’t you?

Quality assurance

Another almost forgotten issue regarding web development is quality assurance. Deadlines are tight, developers are stressed, the application looks nice, so… who cares if a variable is missing or a method of a class goes nuts? It is unlikely to happen, we all have tested functionality and everything works.

Well, that’s again a wrong argument. Experience says that the cost of solving a bug is more than ten times the amount of resources needed to prevent it from the beginning. Think of it:

1. A customer has the application exploding when she tries to use a functionality we hadn’t previously tested.
2. She calls customer support, this produces several messages going back and forth from one part to another until the bug description reaches the development team.
3. A developer, usually not the one that wrote the code, has to spend hours deciphering it (remember about documentation?), reproducing the bug, understanding the underlying problem and fixing it. If this code is more than a few months old, the effort to reload it on a mental representation is several times bigger than if the bug was fixed on the initial development cycle.
4. A new version / patch has to be released and delivered to one or all clients, producing service temporary interruptions.
5. Excuses, apologies, unhappy costumers, official communications explaining how to fix the bug…

Why wouldn’t we prefer to test thoroughly the application and fix all critical failures before moving to production? Are architects, or Aeronautics engineers forced to deliver their work without ensuring quality? Then why are we, software companies?

Conclusions

This traditional point of view of Engineering processes (it has actually been long time used for Electronics design) might seem outdated when applied to web applications, and more precisely web “2.0″ systems. Nowadays, projects need to develop fast, deploy quickly and have a soon ROI. Is it a misunderstanding to still apply these four principles?

It is not, in my opinion. While it might seem meaningless for that 80% of medium-small web sites based on a few interfaces and some custom CMS’s, it is absolutely necessary for bigger home-brew apps. Otherwise, spaghetti-code, lack of documentation, coupled modules and many other big mistakes shall occur and the time is to come were our beloved application will need to be rewritten from scratch, or fall into oblivion.

I am afraid I have seen it before, and not just once.

Besides of a time line of the application execution, it creates an histogram to present where your application spends more resources and what the most called functions are.

Take a look to the launcher example for usage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

import Profiler.Profiler;
 
public class launcher {
 
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Profiler pf = new Profiler();
 
		pf.start();
 
		pf.sleep(219);
 
		pf.checkPoint("one");
		pf.sleep(123);		
		pf.endCheckPoint();
 
		pf.checkPoint("two");
		pf.sleep(245);
		pf.endCheckPoint();
 
		pf.checkPoint("one");
		pf.sleep(13);		
		pf.endCheckPoint();
 
		pf.checkPoint("two");
		pf.sleep(25);
		pf.endCheckPoint();
 
		pf.checkPoint("one");
		pf.endCheckPoint();
		pf.checkPoint("one");
		pf.endCheckPoint();
		pf.checkPoint("one");
		pf.endCheckPoint();
		pf.checkPoint("one");
		pf.endCheckPoint();
		pf.checkPoint("two");
		pf.endCheckPoint();
		pf.checkPoint("two");
		pf.endCheckPoint();
		pf.checkPoint("two");
		pf.endCheckPoint();
 
		pf.sleep(194);
 
		pf.end();
 
		System.out.println(pf.toString());		
 
	}
}

The code above will produce:

The whole process took          821.556 milliseconds

1171994752050889 >> one took    122.580 milliseconds
1171994874654460 >> two took    245.045 milliseconds
1171995119708510 >> one took     13.648 milliseconds
1171995133362201 >> two took     25.382 milliseconds
1171995158749506 >> one took      0.005 milliseconds
1171995158757886 >> one took      0.003 milliseconds
1171995158764312 >> one took      0.004 milliseconds
1171995158771017 >> one took      0.003 milliseconds
1171995158777442 >> two took      0.003 milliseconds
1171995158783867 >> two took      0.003 milliseconds
1171995158790013 >> two took      0.064 milliseconds

Profiler information
CheckPoint     Frequency         Time      % Time
one                    6      136.244      16.58%
two                    5      270.498      32.93%

Download the code here. Please feel free to use it, adapt it and don’t forget to send me back your changes!

However, that’s not all of it. The method above will never work unless you set the right permissions for the user ‘anonymous’ to the database you want to access. That’s it: individual database access must be configured, as it is explained here. The official reference can be also of help, although a bit outdated.

Even then, we had a lot of trouble working with the WebDAV enabled browsing. Under Windows 7 with Explorer, it seemed not allow any kind of file copying – but it allowed to create folders and files by right clicking directly on the directory, though. Also, we were having problems on MAC OS Finder in form of random write errors. All this stuff was pretty confusing and unclear on every forum and blog that we visited for help.

So, eventually, we found out a solution: do not use Explorer nor Finder at all! There are good WebDAV tools that work much like an FTP client (like Cyberduck or BitKinex’s WebDAV client that work very well and do not present the problems we had with the OS built-in clients.

In addition, both clients support authentication, which allows to connect using our own credentials instead of having to open the database access to all anonymous connections (a clearly potential security breach). We just had to configure the database to support ‘design locking’ since it is used by some WebDAV clients on write operations.

To sum up, the key points to make Lotus Domino WebDAV work are:

• Configure the server to allow WebDAV connections. This is done once for all databases.
• Configure the database for design blocking (required for some clients) – no need to change access permissions!!
• Use any other WebDAV client than the OS’s built-in ones.

Update: It seems like Domino requires specific permission rules for the databases being accessed via WebDAV. A user ‘Anonymous’ is required with explicitely no access at all: otherwise, when trying to connect with your own user, being a web interface (whose default user is, by the way, ‘Anonymous’), Domino seems to stop processing access rules at this profile, therefore not allowing any further connection.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function getCSS(filename){
  var fileref = document.createElement('script');
 
  fileref.setAttribute("type", "text/javascript");
  fileref.setAttribute("src", filename);
 
  var handleLoad = dojo.connect(fileref, 'onload', function(evt) {		
    console.log('the element ' + evt.target.src  + ' loaded');				
    dojo.disconnect(handleLoad);		
  });
 
  var handleError = dojo.connect(fileref, 'onload', function(evt) {		
    console.log('the element ' + evt.target.src  + ' failed loading');				
    dojo.disconnect(handleError);		
  });
}

While this approach should normally be the right one, there is a problem with the ‘onload’ event that should be fired after the link DOM element has been inserted into the page header and the CSS file has been loaded. However, Firefox is not firing the onload event for CSS link elements, and IE is doing it only the first time; that’s to say, the code above will hardly work and if it does, it will not take the browser’s cache into account. What a mess!

There is another approach that seems to work, though. After all, CSS is only text, and another way to add CSS to your pages is through ‘style’ elements. So the technique would consist on creating a DOM style element, loading its content with an AJAX call for the CSS file (or dynamic service!), then adding this content as the inner DOM element text. Well, there are small differences between IE and the other browsers, but the solution is working for me.

After reading in the dojo Trac that there is not such a thing as a ‘dojo.requireCSS’ component (which by the way works neatly for JS files), I found that the workaround explained above could be easily implemented with this framework. The reason that the example suggested is not become official is that, due to browser’s inconsistencies, it is not possible to control the onload events (it is based on link, not style elements). However, we can apply the workaround to the suggested dojo library to make it work. The next code block explains the result:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142

dojo.provide("dojo.requireCss");
 
(function(){
	var cssCounter = 0;
	var cssInFlight = {};
	var cssInFlightIntvl = null;
	var cssStartTime = 0;
	var cssCache = {};
	var callback = null;
 
	var _watchCssInFlight = function(){
		//summary: watches to make sure all css files have loaded.
 
		var stillWaiting = false;
		console.log(cssInFlight);
		for(var param in cssInFlight){
			if(typeof param == "string"){
				console.debug('waiting for ' + param);
				stillWaiting = true;
			}
		}
 
		if(stillWaiting){
			//Make sure we have not reached the timeout stage.
			var waitInterval = (dojo.config.cssWaitSeconds || 15) * 1000;
			if((cssStartTime + waitInterval) < (new Date()).getTime()){
				var err = "Timed out waiting for css files: ";
				for(param in cssInFlight){
					err += param + " ";
				}
				throw err;
			}
		}else{
			//All loaded. Clean up.
			console.debug("all done");
			clearInterval(cssInFlightIntvl);
			cssInFlightIntvl = null;
 
			// finally, launch callback if any
			if (callback != null){
				callback();
			}
		}
	}
 
	dojo.requireCss = function(/*String*/resourceName,/*function*/func){
		//summary: Converts the resource name ("some.thing") to a CSS URL
		//(http://some.domain.com/path/to/some/thing.css), then adds the CSS file
		//to the page. Full urls can be passed in (instead of a "some.thing" resourceName.
		//It also registers this CSS file with the dojo loader. This
		//means that if you do a dojo.addOnLoad() callback after calling this function,
		//the addOnLoad callback will not be fired until the CSS file has loaded.
		//Note that style sheets may be evaluated in a different order than the order
		//they appear in the DOM. If you want precise ordering of style rules, make
		//one call to this function, then in a dojo.addOnLoad() callback, load the other,
		//and repeat this call structure until you load all the stylesheets.
		//Example:
		//		dojo.requireCss("some.thing");
		//		dojo.requireCss("http://some.domain.com/path/to/some/thing.css");
 
		// Customization: avoid the process if the resource was loaded before
		if (cssCache[resourceName]){
			console.debug(resourceName + ' was already loaded');
			return true;
		}
 
		//Translate resource name to a file path
		var path = resourceName;
		if(path.indexOf("/") == -1){
			path = dojo._getModuleSymbols(resourceName).join("/") + '.css';
			path = ((path.charAt(0) == '/' || path.match(/^\w+:/)) ? "" : dojo.baseUrl) + path;
		}
		if(dojo.config.cacheBust){
			path += (path.indexOf("?") == -1 ? "?" : "&") + String(dojo.config.cacheBust).replace(/\W+/g,"");
		}
 
		//Create the style node
		var style = dojo.doc.createElement("style");
		style.type = "text/css";
		cssInFlight[path] = style;			
		console.debug(path + " created");
 
		// Customization: add it to an internal register so that it is not loaded twice
		cssCache[resourceName] = true;
 
		// now get the content with support for hooks
		dojo.xhrGet({url:path}).then(function(response){
			if (style.styleSheet){
				// IE	
				var imports = response.match(/@import\s+url\s*\(\s*['|"]([^'|"]+)['|"]\s*\);?/g);
				if (imports) {
					iMax = imports.length;
					for (i=0; i<iMax; i++) {
						imports[i].match(/['|"]([^'|^"]+)['|"]/);
						dojo.requireCss(RegExp.$1);
					}
				}
				style.styleSheet.cssText = response;
			} else {
				// the others
				style.appendChild(document.createTextNode(response));	
			}		    
 
			console.debug(path + " loaded");
			delete cssInFlight[path];
 
			if (typeof func == 'function'){
				func();
			}
 
		    return(response);
		});
 
		//Attach the node to document.
		if(!this.headElement){
			this._headElement = document.getElementsByTagName("head")[0];
 
			//Head element may not exist, particularly in html
			//html 4 or tag soup cases where the page does not
			//have a head tag in it. Use html element, since that will exist.
			//Seems to be an issue mostly with Opera 9 and to lesser extent Safari 2
			if(!this._headElement){
				this._headElement = document.getElementsByTagName("html")[0];
			}
		}
		console.debug(path + " adding to head");
		this._headElement.appendChild(style);
 
		//Start the inflight watch.
		cssStartTime = (new Date()).getTime();
		if(!cssInFlightIntvl){
			cssInFlightIntvl = setInterval(_watchCssInFlight, 100);
		}
	}
 
	// some public functions
	dojo.requireCss.setCallback = function(/*Function*/func){
		if (typeof func == 'function'){
			callback = func;
		}
	}
})();

Note: The original code by jburke on the dojo Trac project has been slightly modified to add functionality and to avoid some bugs. In particular:

• The function _watchCssInFlight has been simplified to its limits due to an error on IE (an infinite waiting loop was started). However, I’d recommend to take the original version and test it on your project, since the functionality it adds is beyond this simplified version’s one.
• A cssCache has been added so that resources are only loaded once.
• IE does not originally support style.appendChild(textNode), so a workaround is needed to do so.
• @import clauses in dynamic style tags are not supported by IE. To fix that, requireCss is now a recursive function: each CSS file loaded is scanned for @import declarations (take a look at the regexp!), and for every new CSS imported, an asynchronous call is done. Because files are only loaded once, this matches the normal browser behavior to solve this particular problem.
• A callback can be set so that it is fired once all CSS resources in the current page have been loaded. It can be useful to control CSS loading, then launch JS asynchronous loading (with dojo.require, for instance), or any other action. The module could be extended to accept also callbacks after individual elements have been loaded.

Further tests have to be done with this component, and I take no responsibility if you use it for your own projects, but it has already solved a problem for me and, as far as I’ve checked, it is working on the latest versions of Firefox, IE, Safari, Opera and Chrome. Until there is an official solution to this integrated in the dojo toolkit, this fills the gap.

Let’s say you are in charge of porting a desktop application to the web environment; you have to change the paradigm and start using CSS, JS (lukily even a framework like Dojo) and finally HTML. Your webapp has menus, submenus, a lot of stuff and many different forms, interfaces and views to present and collect the information to and from the user.

And at some point you discover what iframes are, and may you think “they might well pay the effort, I can create every single interface separately and finally integrate them into the full framework, like a puzzle”. Don’t. They are not worthy, and you’ll find out why too late. Seriously, while iframes are useful in some practical situations (when there is absolutely no other solution), they bring in some major drawbacks when used to build the interfaces of your rich web app:

• The JS top layer application does not know about, and therefore cannot access, the DOM elements in inner frames.
• CSS heritance is not respected, so there is no way to ensure what the inner frame is going to look like – unless CSS files are loaded again (see below).

As a consequence of this two effects, both related to the very nature of an iframe (to load an external page into your site), every CSS and JS file must be loaded again in every inner frame so that the app can run, which produces a waste of server’s resources and slows the page load, which in turn impacts on user experience. Of course you can compile your files in production to alleviate this, but it is not going to fix the maintenance problems and the hacks and turnarounds that you’ll need to apply in order to get your web app working as expected. Not to talk about big applications: centralizing the logic of your SAAS in one main class is going to be very painful due to the limitations said above. And not centralizing such kind of huge logic (that’s to say, classical event-driven approach) can turn your best efforts to create a coherent code into a considerable mess. When your application grows and you realize about these limitations, there is not going to be a turnaround, and you’ll have to deal with an unstoppable monster.

Yeah, yeah, I know: they come in handy; they are easy to implement; they are useful and shinny; but moreover, they are very, very evil. Please, stop using them! If you ever have had to refactor a medium sized JS application based on iframes, you surely know what I’m talking about… otherwise, please, do yourself a favor (and to the ones that will come after you) and avoid those damn iframes. Please! I beg you!

Further reading:

• http://blog.archive.jpsykes.com/126/dojo-and-iframes-tip/index.html
• http://www.thespanner.co.uk/2007/09/09/iframes-are-evil/
• http://stackoverflow.com/questions/96748/are-iframes-a-terrible-idea

Imagine a relationship between students and classrooms. Every classroom can have N students, meaning this zero, one, or many pupils. From the other side, every student must have a classroom, otherwise she won’t be allowed to study. This is a classic 1:n relationship, used in most of the real cases that we may encounter.

But what if, let’s say, a student had finished her studies and, however, wasn’t deleted from the database? (just to keep the records and other sensible information). In that case, the statement ‘every student must have one and only one classroom’ would be wrong. Instead, we could say ‘every student can have one classroom or none’. Now we are talking about zero or one to many relationships.

A practical situation for this type of relationships are tree structures on auto-referenced tables. For instance, a category tree where every tuple can have a parent or none (thus being at root level). While a possible solution to this problem might be to create a ‘fake’ root element that all the others inherit from unless said otherwise, this approach forces the design to include a ‘meta element’, not meant to represent data at all. That’s to say, it has to be programmatically removed from all database queries so not to have it poking around.

The right solution to this problem is making the foreign key nullable so that we can effectively represent the case when there is no parent while respecting relational integrity. In addition, the cascading options on deletion should be set as ‘set null’ so that a possible deletion of a classroom does not delete all the students that might be related:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

-- ------------------------------------------
-- Table classrooms 
-- ------------------------------------------
CREATE TABLE classrooms(
  classroomID INT NOT NULL AUTO_INCREMENT ,
  classroomName VARCHAR(50) NOT NULL ,
  PRIMARY KEY (classroomID)
) ENGINE = InnoDB;
 
-- ------------------------------------------
-- Table students
-- ------------------------------------------
CREATE TABLE students (
  studentID INT NOT NULL AUTO_INCREMENT ,
  studentName VARCHAR(50) NOT NULL ,
  classroomID INT DEFAULT NULL ,
  PRIMARY KEY (studentID) ,
  CONSTRAINT fk_students_classrooms
    FOREIGN KEY (classroomID)
    REFERENCES classrooms.classroomID
    ON DELETE SET NULL
    ON UPDATE CASCADE
) ENGINE = InnoDB;

Further reading: here and here.

In these times where cloud computing has settled and means to stay, it is very likely that our web interface is going to use several toolkits, libraries, widgets, plugins from different frameworks (such as jQuery, Dojo, Mootools), which, if used out of a coherent system, will produce a lot of server calls to download the related resources. Not only this adds up to server load, but it also can increase total load time by several magnitudes, which, in turn, makes the user feel that the entire web application is slow and crappy.

Just a few details we should never forget when optimizing our web interfaces to avoid the effect above (and this goes more as a self-reminder than as a hint):

• Use the right headers so that your image, CSS and JS files are kept in browser’s cache.
• Make sure that gzip compression is active on the server.
• Minify the JS/CSS files before putting them in a production environment.
• Use sprites for GUI pictures.
• Use a dynamic loader that grabs the related resources on-demand and asynchronously.
• Combine JS/CSS files into modules.

There are, of course, many more things you can do to ensure that your application runs smoothly, but the ones above are relatively easy to apply, and produce results in the middle / short term.

Any suggestions? Comments are welcome.

It has been designed to be light though structured and functional. It is intended for people who need to develop home-brew solutions and are not happy with the footprint of other frameworks, or for those who just want to have fun while creating their own MVC system.

If you are interested, visit the page for documentation and download here.