Creating a good API

Unlike writing end-user software, writing an API has two purposes. You must be able to have the developers understand how to use it fairly consistently, but you also must write it so that their end users get the performance that they need. In briefcase we have run into this problem in the form of a simple problem: to use multiple javascript files or not. The argument for using many files is that the code become easier to manage, you can create a file for each of the main focuses of your project. The downside and the argument against multiple files is that for each file you need another HTTP request to the server to get it. I believe that we have come up with a clever solution to this problem. The only files that we as the API creators are considering at the moment are the shared libraries, saving and loading, global menu, context menu, hotkey, infinite onload, etc. Our solution is to write them ourselves in multiple files, each section of the code gets its own little file to sit in and contemplate its existence. When we are done, or would like to release a new version the code is “compiled” into one file. Compiling will do two things. The first one is to simply squish all of the libraries into to one file. The second is to minify it, jquery uses a program called UglifyJS but more research definitely needs to be done.

– Asher

Meta Javascript

As my work on briefcase revs back up I wanted to figure out how to solve a problem that I ran into with multiple libraries.
The problem is with the ‘onload’ variable
JQuery does a nice job handling this by creating a new function, they even changed the way it works to their own custom implementation that only waits for the html to load not the pictures and ads. However this is not what I was after. I wanted a method that would be able to take two pieces of code that both had onload commands, for example a menu library and the actual application.  After a little bit of research i stumbled upon a function call defineProperty(). Using this function I was able to create the code below.

<pre>
onload = function () {alert("Not Loaded")};
onload = function () {alert("Loaded")};

// You probably dont want to have two onloads being set
window._onload = [];
window._onload.push(window.onload);
window.onload=function(){for(a in _onload) {_onload[a]()}}
Object.defineProperty(window,"onload",{get:function()){return this._onload},set:function(n){this._onload.push(n);}});

// Lets add a few more onloads to test the process
onload = function () {alert("Loaded2")};
onload = function () {alert("Loaded3")};

below This code has four onload functions being created. The first two onload calls are present before the code begins handling the onload commands, the second two appear after.

The very first onload statement will get overwritten by the second, however the third and fourth statements will all get run along with the first

New Interest in our Project

A few people have talked to me about joining our project, however we are still focusing on developing the API for building and using the briefcase interface. However there are some key tasks that need to be acomplished in order to get Briefcase fully off the ground. As a result I will be creating two groups to work on Briefcase. The first group is Briefcase – Core. We will be working on the core API and functionality of Briefcase including the menu system, Django server, the user input configurations, along with the spreadsheet and code editor applications. The second team will be the Briefcase – Dev team. They will be in charge of integrating Briefcase with Apache and other webservers, creating a front facing web site with helpful info about how to use and install Briefcase (the github wiki is just not cutting it anymore), and help run tests on Briefcase-Core. I hope to be able to get a few younger students to help out with this as a good way to introduce them to RCOS and a good way to get code written for the project.

– Asher

Lack of recent work and multi user editing

The amount of work that has been put into briefcase of late has been very minimal. And I would personally like to apologize to those who want this project to be further developed. However, Now that my current life’s issues have been worked out I will be putting in more hours of the day to this project. I will begin by laying out a schedule for what will happen in the future.

The two applications that I would like to have completed first are the spread sheed and the coding document. However before either of those will continue I will first finish the multi user editing. For the most part this will be a very simple task, merely sending organized data to each of the clients. However, for applications like the code document and other general text editors, you also have to do some error checking on the location of the inputed characters. This is what I believe will be the most challenging part of the project. I hope I know enough django to solve this problem.