Tine 2.0 is now able to upload multiple files at once. Additionally Files can be uploaded from directly out of the operating systems file manager or desktop using drag & drop.

Being an open source project, it’s extremely important for us to chose freely available standard technologies. Therefore it has to to be emphasized, that these new features run in FF, Chrome and Safari without any additional plugins.

The ExtJS wrappers for File Browsing are wrapped into
Ext.ux.file.BrowsePlugin

HTML 5 File uploading for ExtJS is wrapped into
Ext.ux.file.Uploader

Prepareing a JSON Service Map Description

To use the Ext.direct framework we need to register a provider. For a remoting provider we need a service mapping description.

Ext.Direct.addProvider(Ext.apply(Ext.app.JSONRPC_API, {

    'type'     : 'zfprovider',
    'url'      : Ext.app.JSONRPC_API.target
}));

Ext.app.JSONRPC_API holds the service mapping description which in the Tine 2.0 case we deliver it with our registry data, but you can also fetch it e.g. by a javascript include as suggested in the “EXT.DIRECT REMOTING SPECIFICATION”.

<script src=”index.php?method=Tinebase.getServiceMap” type=”text/javascript”></script>

The Service Map could be generated like this:

$server = new Zend_Json_Server();

// set all classes you want to expose
$server->setClass('MyModule_Service_Json', 'MyModul');

$server->setTarget('index.php')
    ->setEnvelope(Zend_Json_Server_Smd::ENV_JSONRPC_2);

$smdArray = $server->getServiceMap()->toArray();
// save some bytes
unset($smdArray['methods']);

echo "Ext.app.JSONRPC_API = " . Zend_Json::encode($smdArray);

Ext.ux.direct.ZendFrameworkProvider

To Enable Ext.Direct to understand the JSON-SMD data and also communicate using the JSON-RPC protocol we create an own provider:

Ext.ux.direct.ZendFrameworkProvider = Ext.extend(Ext.direct.RemotingProvider, {

...

At first we need to parse the JSON-SMD and to create the stubs. This is done by overwriting the initAPI method:

// private

    initAPI : function() {
        for (var method in this.services){
            var mparts = method.split('.');
            var cls = this.namespace[mparts[0]] || (this.namespace[mparts[0]] = {});
            cls[mparts[1]] = this.createMethod(mparts[0], Ext.apply(this.services[method], {
                name: mparts[1],
                len: this.services[method].parameters.length
            }));
        }
    },

All we do is to transform the JSON-SMD definition data in to a from the original createMethod method can understand to create the stubs.

It’s important to understand, that the createMethod creates stubs which do only trigger further processing of the provider and do _NOT_ contain all the code to do requests and protocol processing.

Once a stub is called, it applies the doCall function of our provider. In order to support named parameters we inspect the call and transform a named parameter call into a positional parameter call. This is needed, cause the ZendFrameworks Zend_Json_Server is itself not able to understand named parameter calls witch by the way are indeed part of the JSON-RPC specification.

// private

    doCall : function(c, m, args) {
        // support named parameters
        if (args[args.length-1].paramsAsHash) {
            var o = args.shift();
            for (var i = 0; i < m.parameters.length; i++) {
                args.splice(i,0, o[m.parameters[i].name]);
            }
        }

        return Ext.ux.direct.ZendFrameworkProvider.superclass.doCall.call(this, c, m, args);
    },

After the parameters a prepared, the provider assembles the request according to the protocol definitions. This is done in the getCallData method.

// private

    getCallData: function(t){
        return {
            jsonrpc: '2.0',
            method: t.action + '.' + t.method,
            params: t.data,
            id: t.tid
        };
    },

This protocol encapsulation only deals with single transaction calls. The processing for batched calls is done elsewhere. Luckily The both protocols use the same simple outer array for batched calls, so that we don’t need to touch it.

Finally the response needs to be decoded according to the protocol and the callback function needs to get called using the decoded data. This is done in the onData method:

// private

    onData: function(opt, success, xhr) {
        var rpcresponse = Ext.decode(xhr.responseText);
        xhr.responseText = {
            type: rpcresponse.result ? 'rpc' : 'exception',
            result: rpcresponse.result,
            tid: rpcresponse.id
        };

        return Ext.ux.direct.ZendFrameworkProvider.superclass.onData.apply(this, arguments);
    }

And voila, thats it. This is our custom provider to enable Ext.Direct to use and talk pure standard JSON-PRC/JSON-SMD.

Finally let’s register the provider for lazy invocation

Ext.Direct.PROVIDERS['zfprovider'] = Ext.ux.direct.ZendFrameworkProvider;

Server Side Batched Requests

As noted in Part 2, the biggest problem with the Zend_Json_Server is the fact that it’s not capable to handle batched requests yet. To overcome this in a simple way, you can monitor the first character of an JSON request in your dispatcher and dispatch multiple request if it’s a ‘[‘. Of course this is far away from optimum, but it’s a start point till we have the feature in the Zend_Json_Server.

Ext.direct is a namespace and a bit of a buzzword in the ExtJS 3.0 release. In short, the Ext.direct stuff introduces high level communication features.

The key component of these new features is the “EXT.DIRECT REMOTING SPECIFICATION” which covers the aspects ‘remote procedure call‘ and ’service description’. Ext.Direct implements this specifications within the ExtJS framework as service consumer and for multiple server side stacks as service provider.

Besides having a well defined and documented communication and transport layer Ext.direct also has the advantage, that other ExtJs classes dealing with data can work on the stubs, created based on the ’service map descriptions’. The Ext.tree.TreeLoader can be configured with a directFn to fetch it’s data. More over the Ext.data.DirectStore can be configured with a complete set of direct functions for CRUD actions.

An other cool thing about the javascript implementation of the Ext.direct.RemotingProvider is, that is queues request of the direct stubs for a configurable time span. After this span, it sends one batched request to the server.

However, its important to note, that the “EXT.DIRECT REMOTING SPECIFICATION” is different form the JSON-RPC/JSON-SMD specifications introduced in part 1.

While digging in the specs I found some pros and cons for the “EXT.DIRECT REMOTING SPECIFICATION” compared to the JSON-RPC standardization:

• + It covers form posts which are needed for special actions like file upload
• + It covers events send by the server
• - It lacks of function parameter description
• - It does not support named function parameters
• - It does not support optional parameters
• - It is not compatible to the JSON-RPC standardization efforts

The last point is IMHO the strongest point why not to use this specification. While the rest of the javascript/webservice addicted world tries to find a common standard, ExtJs goes its own way. There are already a number of implementations for the JSON-RPC and JSON-SMD out there, and more and more will follow. I also expect to see service consumers written in PHP which ease writing server-server web-services using the same API.

For that reasons I choose to take the standard Zend_Json_Server implementation and to write a Ext.ux.direct.ZendFrameworkProvider we can use in Tine 2.0 and other Zend Framework based projects.

It’s only fair to note, the the Zend_Json_Server also has several issues which needs to be improved. Most notably:

• - It does not support batched requests
• - It does not support named parameters

After all this theory I’ll cover the actual implementation of the Ext.ux.direct.ZendFrameworkProvider in part 3.

When we started to implement Tine 2.0 about 2 years ago, we got quite some confused request why we chose JSON over SOAP as our data transport between the server and the client. Technically the answer is very easy. JSON protocols only need a fraction of the bandwidths and even more important JSON has a significant better performance on client side, cause no XML parsing is needed.

On the other hand, two years ago SOAP was a mature protocol but JSON only an data encapsulation and no real standards did exist, so that we where forced to implement a custom protocol.

Fortunately this has changed in the last two years. There are three cool standardization efforts in the JSON community I’d like to introduce.

1. JSON-RPC: It’s a lightweight remote procedure call (RPC) protocol. The clients request consist only of a single JSON data telegram and does not use HTTP parameters:
   

   --> {
       "jsonrpc":"2.0",
       "method":"Tinebase.login",
       "params": {
           "username":"tine20admin",
           "password":"lars"
       },
       "id":2
   }

   
   

   <-- {
   "id":"2",
   "jsonrpc":"2.0",
   "result":{
       "success":true,
       "account": {
           "accountId":"0e7d07cb453b15f520021e0a433956b234a7c0bd",
           "accountDisplayName":"Admin Account, Tine 2.0",
           "accountLastName":"Admin Account",
           "accountFirstName":"Tine 2.0",
           "accountFullName":"Tine 2.0 Admin Account",
           "contact_id":"1"
       },
       "jsonKey":"85160b59b4421bbe2f350c5b3888a2efdbfcb949",
       "welcomeMessage":"Welcome to Tine 2.0!"
   }}

   Multi batch calls are also possible. The client only has to send an array of request objects. Unfortunately the Protocol does not handle “Form-Posts” which are necessary for some special actions like file-uploads.

   But nevertheless libraries are starting to implement the spec and this is the most important thing about it!

2. JSON SMD: It’s a JSON representation for describing a web service. The server ‘exposes’ it’s services to the client.
   

   {
   "transport":"POST",
   "envelope":"JSON-RPC-2.0",
   "contentType":"application/json",
   "SMDVersion":"2.0",
   "target":"index.php",
   "services": {
       "Tinebase.login":{
           "envelope":"JSON-RPC-2.0",
           "transport":"POST",
           "parameters":[{
               "type":"string",
               "name":"username",
               "optional":false
           }, {
               "type":"string",
               "name":"password",
               "optional":false}
           ],
   "returns":"array"}}}

   The client can use this descriptions to automatically create the stubs for calling the services which already encapsulates all the proxy and transport and protocol overhead. With this, instead of creating an AJAX request per hand you only have to call the method:

   Tinebase.login('tine20admin', 'lars', cb);

   where cb is a callback function, cause we do our requests asynchronous.

3. JSON Schema: Quoting their website: “JSON Schema is a specification for a JSON-based format for defining the structure of JSON data.”
   Of course the idea is pretty old in the world of web-services, but it’s the first approach to bring this to the new area of javascript based RIA’s which use JSON for the reasons stated above.With this we not only expose the services to the client, but more over also the data types. The benefit is clearly that we don’t need to maintain the data models client side and also the client side data validation could be made client side automatically.

In Part 2 I’ll introduce Ext.Direct and go into the details how to apply this new standards within the Ext.Direct framework.

At the moment I have Day, Week and Monthview working. The Day and Week view supports direct creation of Events using dblclick or a mousedown/mousemove combination. All views support drag and drop of events. For fast switching of views, you can click the jumppads (dayheaders/weeknumer).

I made a litte MemoryProxy as Backend for the demo bellow, so you can change views and move around in time. The whole demo is Javascript only. The Calendar views are designed like normal ExtJS widgets and should be highly reusable. If you want to join development for them, please drop me a note.

Tine 2.0 Calendar All Tests
Calendar_RruleTests
............

Calendar_Backend_SqlTests
.......

OK (37 tests)


Most of hard work behind the scenes (aka backend) is finished. Implementing the recuring rules to behave correctly for participants in different timezones was quite a challenge, but I’m quite hopeful that with our implementation we won’t have the moving events after ‘Day light saving’ boundaries like we had in the other project.

This week I’ll start to implement the interfaces based on ExtJS. Anne already gave some great impact on the calendar organization schema. Please do support her survey coming up in the next days.

After the campaign for new translators, we got new translators for Spanish(en), French(fr), Dutch(nl), Portuguese(pt) and  Traditional Chinese(zh_TW). At the moment, they are working on the translations for our current stable release (Lara). If the translations are finished, we’ll add them to our next service release for that version.

So here a little snapshot of current development progress, feel free to leaf you comments.

The installation requirements are not met. It's not possible to continue setup. Maybe we also need some kind of alert "Your server is not capable to run Tine 2.0. Sorry!"

Setup checks are passed, but no config file is found. Here we need a little form to support creation of a config.inc.php file.

If a config file is present, you need to login into setup (credentials from config.inc.php)

You have a config file and successfully logged in, but something is not working with your config, e.g. SQL or LDAP is down.

If all requirements are met, you are ready to run the application manager. This is the place to install / uninstall and upgrade your applications

Whats the scope of the setup?

In the setup all things needed to run Tine 2.0 itself should be configured. This is the main database connection on the one hand, and the authentication and account drivers on the other hand. Things like email, voip, langs etc could be configured directly from the admin section in Tine.

Filter all timesheets from last month whoose timeaccount-numbers start with a certain string.

Select some Timesheets and mark them as billable too.

Add a filter to only find billable timesheets and select all 259 Timesheets which got found.

Now we export all selected timesheets as ODS to write our bill in Open Office

Finaly we again use mass update to mark all timesheets, found by our filter, as cleared and add in which bill we cleared them.

To avoid double billed timesheets, it would have been a good idea to filter for non cleared timesheets too

• Ext.Window’s have a different style than the native operating system windows. This may confuse users, especially those, not familiar with the technical background in web apps.
• Ext.Window’s can’t be dragged out of the browsers viewport. Users with large or multiple screens will feel limited with those windows.
• Users don’t want to have an extra window manager inside the normal operating systems window manager. Just look back to the ugly star-office approach, which we all hated.

As a consequence we decided to use native windows in Tine 2.0. However, dealing with native windows in a Javacript application turned out to be a non trivial thing. A new browser window brings a new javascipt context and we needed to find a way to bring our content into the new context. Also we needed to find a way how windows can communicate. The opener.location = opener.location from the good old Web 1.0 times obviously is not adequate any more . Thinking about offline functionality brought even more complexity to the system. When the Browser is offline, you need to create windows without any help of a server.