Mechanisms for Large Javascript Project Developments(2)

--project definition

Project Layout

In this chapter we will see the physical layout of a project, which provides a module and a webapp at the same time. If you have registered in https://qyapp.com, a project named sampleproj is auto created for you to try out. You can open Qiyun Project Management Tool to exam its file structure, which is as follows:

1. index.html. This is the stub. It is necessary only because the browser needs an html url to start with. Normal you don't need to change anything inside it.

2. start.js. This is where your webapp starts. It is also quite simple. The code normally is like:

qyboot.ready(function(){
    var mod = using(SelfModName());
    var desktop = new mod.myDesktop({});
});
                

3. myDesktop.js and myDesktop.design.js. These two files determine the UI and the event handling code. myDesktop.design.js is auto generated by Qiyun IDE. It uses plain Javascript to define how your UI looks like. myDesktop.js is where you keep all your event handling code, e.g., if a button is clicked, what you expect to do.

4. A folder named css. This folder keeps all your css and related images. This is actually for coordinating developers and designers. Designers author css code, prepare images while developers implement the design and logic in Javascript code. We will further discuss how solution based development model can let the team do their own work parallel and distributed while at the same time unite as a whole. The simple idea is that we have css as a separate project and through using_css(“path/to/css/proj”) or inside_using_sln_css(“solution relative path”) to reference the css code in the javascript project.

5. A folder named locale. It keeps some Javascript files to define your UI's locale data. A locale is defined as follows:

DEFINE_NAMESPACE(function(ns){
    DEFINE_LOCALE("en-US",{
        “selected_msg”: function(lang){
            return “You selected %s”.print(lang);
	}
    });
    DEFINE_LOCALE("zh-CN",{
        //add your locale content as follows
	"English":"英文",
	"Chinese":"中文",
	"selected_msg":function(lang){
	    return "你选择了%s".printf(lang);
	}
    });
});
                

6. A folder named rpc. It keeps your backend logic code. You can write your backed logic code in Javascript and it will be compiled and directly run in our cloud. We also provide WebSocket support so that you can write WebSocket server code in Javascript and directly communicate with your client UI.

The code in proj.rpc.js is as follows:

//export a function so that it can be called by ns.remote.fact(10)
function export_fact(n){
    var total = 1;
    for(var i = 2;i < n;i++){
        total *= i;
    }
    return total;
}
                
//export your function so that it can be called by ns.remote.queryFriend(“New York”);
function export_queryFriend(city){
    return MyDB.table(“friends”).where({city:city}).select(“username”);
}
                
//export your web socket function so that it can be called by
//ns.remote.ws_sendMessage(“Mary”,”Do you have plan this weekend?”);
function export_ws_sendMessage(receiver,msg){
    RpcGlobal.sendToWs(receiver,{method: ws_sendMsg,args:[msg]});
}
                

We will talk more about this later.

Basically this is it. These are physical files of your project. How do we organize them into a module and a webapp? Through a proj.config file. In this config file, we use JSON to determine which js/css files combine into a module, and which js/css files combine into a webapp. Everything inside a module can be referenced by using(“path/to/the/proj”).

Benefits

Once your Javascript project is organized that way, there are several advantages:

1. The structure is clear. Other people can understand it at a glance. They know where the related part is when they try to find the code.

2. All module js files can be combined into one single file during deployment, but keep separated during development. They can even be encoded and compressed during deployment.

3. When the module is shared, we can use proj.config to determine whether any file is changed. If so we only need to fetch the changed files. This will greatly reduce traffic and enhance the client response time.

Process of Deployment

Let's exam closely what we will do when you deploy sampleproj in our projmgmt tool.

First our cloud server will receive a command to deploy your sampleproj, whether to position debug or position deployed. If to debug, that means you like to retain the code as is. If to deployed, our cloud server will load your proj.config, determine which css/js files can be combined, then combine them and use tools to encode and compress the result file. The output file is compact and hard to read.

Then a deployed proj.config will be produced to keep some time stamp information. If your project has rpc code, it will be compiled and deployed in our cloud server at this step.

Once the deployment is done, you can now use the browser to navigate to your project's url, and see your webapp working.

When using(“path/to/your/proj”) is called to reuse your module in this project, our platform will first try to check whether the server side proj.config is updated. If not, it will use the project cached inside your browser. If proj.config is updated, it will check which file is changed comparing to the cache. Overall only the files that are actually changed will be fetched. And these changes will be cached.

More to Come

There are a lot of details left out. But you can get a rough idea about how projects are organized and the benefit it will bring. There are several topics we will cover in next chapters.

1. project based solution development model. This is for large teams with different source code access privilege.

2. Coding server side logic in Javascript. Specifically we will introduce MyDB and MyFile interfaces and exam how to write code in Javascript that can manipulate DB and file system in the cloud server side. We also write code that will utilize HTML5 websocket to provide a message communication tool. Websocket is well integrated in our platform. You can write less than 10 lines of code to have both client and server logic working.

3. User management in your rpc code. You can have your own user data and easily let someone login or deny his login. This also includes how we do our security check so you don't have to.

4. Distributed Version Control through the web.

5. Smart editor that can do the semantic analysis.

They may not be necessarily in this order. If you are more interested in some topic, feel free to tell us so we can write about it first. Thank you for your interest.

Copyright © 2012 Qiyun Software Co.,Ltd. All rights reserved.