The main reasons for this change are the fast and reliable branching and merging capabilities of GIT. With this, the project hopes to reach an even higher level of development productivity.

As all Contents from the old Subversion got migrated into the new GIT repository the Subversion service got switched off.

Anonymous Access
Anonymous cloning the sources could be done with:

git clone http://git.tine20.org/git/tine20

Switch go the stable branch with

git checkout -b 2011-01 origin/2011-01

Updates could be retrieved with

git pull

Contributors Access
As a contributor please make sure to familiarize yourself with GIT and read one of the dozens of introductions out in the net.

Contributors need to check out per https:

git clone https://git.tine20.org/git/tine20

Usersames and passwords got migrated from the old subversion service

Depending on your Operating system / tools you might need to add a

~/.netrc

with the following content:

machine git.tine20.org
login MYCONTRIBUTORSLOGINNAME
password MYCONTRIBUTORSPASSWORD

• Printing
• Color definition
• Fast responses to invitations
• Quick tip symbols
• Out of view hints

Well, it’s always easy to state that something is slow, so let me be a bit more precise: If you need to do a lot of complex date/time operations in you applications, Zend_Date might turn out to be the major bottleneck. If you just need localization for some date’s Zend_Date presumably won’t be your problem.

In the Calendar app of Tine 2.0 it turned out, that Zend_Date consumes 66% of the time of a Month view Request in a realistic szenario.

Just bashing Zend_Date would be to easy, as it has a remarkable feature set. Most notably in my view:
- solves the year 2038 problem on 32 bit systems
- full timezone support
- full localization support
- full support for ISO 8601 date string identifiers

As Date/Time is a really complex topic, here my full acknowledgement for this feature set at a time when PHP couldn’t help on all this.

On the other hand you don’t always need all the nice features it has, but you might want to use Zend_Date as generic date/time abstraction all over your applications. In this case Zend_Date is slow and has a lot of potential for improvements.

Patching Zend_Date

Zend_Date::__construct($date, $format, $locale)

Zend_Dates could be created from a date string in an arbitrary format and locale. This is great if you need to parse custom date strings.

When dealing with Zend_Date in backend operations, you normally only use very few date/time representation formats. e.g. ‘yyyy-MM-dd HH:mm:ss’ which is the mysql date/time format.

For this kind of input Zend_Date has no optimization. An easy performance patch for this problem could be:

if ($format === 'yyyy-MM-dd HH:mm:ss') {
    $matches = array();
    preg_match("/^(\d{4})-(\d{2})-(\d{2})[T ]{1}(\d{2}):(\d{2}):(\d{2})/", $_ISO, $matches);

    if (count($matches) == 7) {
        list($match, $year, $month, $day, $hour, $minute, $second) = $matches;
        // NOTE: PHP5 timestamp support is 32 bit and ends on 2038-01-19 03:14:07
        if ($year < 2038) {
           $date = mktime($hour, $minute, $second, $month, $day, $year);
           $format = Zend_Date::TIMESTAMP
       }
    }
}

Zend_Date::get($part, $locale)

When converting Zend_Dates to strings, the same as above applies. Here an easy patch could be:

if (! $part) {
    $part = self::TIMESTAMP;
}

if (array_key_exists($part, self::$_dateMap)) {
    $dt = new DateTime('@' . $this->getUnixTimestamp());
    $dt->setTimezone(new DateTimeZone($this->getTimezone()));

    $s = $dt->format(self::$_dateMap[$part]);
    switch($part) {
        case 'm':
            $s = (int) preg_replace('/^0/', '', $s);
            break;
        }
    return $s;
}

with this dateMap

private static $_dateMap = array(
    'yyyy-MM-dd HH:mm:ss' => 'Y-m-d H:i:s',
    'MM' => 'm',
    'm'  => 'i', // spechial handling required!
    'M'  => 'n',
    'd'  => 'j',
    'h'  => 'g',
    'H'  => 'G',
    'HH' => 'H',
    's'  => 's',
    'I'  => 'I',
    'z'  => 'T',
    'U'  => 'U',
    'eee' => 'N',
    'D'  => 'z',
    'e'  => 'w',
    'X'  => 'Z'
);

Zend_Date_DateObject::setTimezone($zone)

As ZF requires PHP 5.2.4 and above, we can use native PHP functions to improve setTimezone:

public function setTimezone($zone = null)
{
    try {
        $dtz = new DateTimeZone($zone);
        $this->_offset   = $dtz->getOffset(new DateTime('1970-02-01 00:00:00'));
        $this->_timezone = $zone;
    } catch (Exception $e) {
        require_once 'Zend/Date/Exception.php';
        throw new Zend_Date_Exception("timezone ($zone) is not a known timezone", $zone);
    }
    if (($zone == 'UTC') or ($zone == 'GMT')) {
        $this->_dst = false;
    } else {
        $this->_dst = true;
    }
    return $this;
}

This are just 3 very easy patches, but for a Tine 2.0 Calendar month view request it saves 41% of the request time!

Avoiding Zend_Date

Derick Rethans contributed a great DateTime class to PHP which is in included beginning with version 5.2 which got even more improved in version 5.3. This class solves the year 2038 problem, has full timezone support.

So my first idea was to write a new Zend_Date class which requires PHP version >= 5.3 to be used as a drop in replacement. Unfortunately it turned out, that the design of Zend_Date is not compatible with the DateTime, or to be more precise, the new class would also be slow due to two base restrictions in Zend_Date:
- ISO representation for date string identifiers
- Zend_Date also represents date intervals which have a separate class in PHP.

At the end I implemented on own wrapper class around DateTime which supports some old Zend_Date signatures, so that we don’t had to edit all our code. Zend_Date is only used when Server side locale handling is needed, like in exports.

Switching from Zend_Date to native DateTime brought us a speed up of 66% in a calendar month view request.

Tine two dot oh

For those of you who are curious what Tine 2.0 stands for, please find my post from 2007/12

If you still need some more input for the next nerd party, you can find the meaning of our version names here.

Superb organisation! Congrats to the whole Team of the “Chemnitzer Linux Tage”. CLT is definitely on the road of becoming _THE_ german Linux community event. Tine 2.0 will be there again next year!

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

As you can guess from the title, the book contains recipes for solving GUI designs with Ext JS 3.0. In total the book comes with 109 recipes divided into 10 chapters.

Chapter 1 gives a short introduction of the Ext JS way of DOM manipulation and other basic things. Together with Chapter 10, which is about design patterns in Ext JS this are the Chapters I like most in the book, cause they help to understand the whole Ext JS picture and present content you won’t find easily in the internet.

The 8 Chapters in between contain receipts as you expect from a cookbook. People familiar with the examples provided in the Ext JS SDK will have sawn about 70% of the receipts presented in the book. In Contrast to the examples in the SDK the printed recipes come with a lot of explanation suitable for beginners with Ext JS and non Javascript geeks. The recipes which are not part of the Ext JS SDK are of high quality and fill the gap where beginners might miss examples.

Chapter 2 tries to give an introduction into the Ext JS layout engine. I use the word “try” as I would expect that the receipts are not enough to explain a beginner the insights needed to understand and create complex layouts. Moreover this chapter misses to explain the new vbox and hbox layouts introduced in Ext JS 3.0. In my view, this layouts are the most important additions to the Ext JS layout engine in the new version.

Each recipe contains the additional sections “How it works” and “There is more”. Both of this sections are helpful for people who don’t just want to cook, but want to gain more insights of the Ext JS framework.

While a recipes book always has newbies and beginners as target audience, this book is not for beginners only. The explanations often stress points which are of importance for experienced users of the Ext JS framework. Moreover the Author frequently gives hints which are of importance for big web applications.

With the precise explanations and the elegance of his own receipts the author proves himself to have an excellent skill level in providing Ext JS based solutions. The examples provided in this book are not just working somehow, they are assembled within the spirit and design constrains of the Ext JS framework itself.

Additionally, it is notable that the version number in the books title reflects the actual state of the contents. In a number of receipts the solution is done using new features which where introduced in the 3.0 version of Ext JS.

In a big online book store, I would rate this book with 4 of 5 stars.

As of now, normally the browser can only communicate with the domain the document being displayed comes from. As always, most restrictions can be circumvented somehow. Quite a while now, the de facto standard approach for cross-site communication in the wild is JSONP.

In short: A javascript located at the foreign domain is inserted in background. Via the GET url parameters the data of the request is send. The script returned by the foreign server contains code which gets directly executed at include time of this script, e.g: callback({jsondata});

It is widely accepted that JSONP should be rated highly insecure for multiple reasons:
- Including a script of a foreign domain is a build in XSS attack.
- All parameters send to the foreign domain are part of the standard access logs of the foreign web servers.
- …

A new idea for secure cross site communication has come up a year ago utilizes the fact, that the name property of browser windows/frames remains unchanged when a window/frame loads a new document even from a foreign domain. With this, it is possible to create a transport by inserting a hidden iframe which switches its document between the origin- and foreign domain.

This approach has the major advantage, that the data returned by the foreign domain is encoded as a string and could be evaluated in a safely. Moreover the request could be done via POST’s which solves EOI issues with server logs.

While I was aware of this new technique, I never had the need to do cross site request from the browser. In general my approach is to proxy data from foreign domains via the server as this gives a better control. However for a Tine 2.0 related customer project I had the requirement to do cross site request from a website to a Tine 2.0 installation directly from the browser.

Unfortunately I didn’t find any extjs/ext-core implementation of the window.name technique. Moreover I realized, that the implementation of other libraries always POST their request using form submits. But doing all request via form Submits would require an additional API for Tine 2.0 as the standard JSON API talks JSONRPC.

So what I needed was a XHTTPRequest/AJAX solution to be able to utilize the standard Tine 2.0 API’s. For this I created a windowNameConnection Proxy which based on ext-core does AJAX requests to the foreign domain. This sequence diagram visualizes it’s simple workings:

You can find the latest version of the implementation here. The usage of this connection class is straight forward as it works like a normal extjs connection:

var connection = new Ext.ux.data.windowNameConnection({
    // this url is autodetected if windowNameConnection is loaded
    // from the foreign domain
    proxyUrl: https://foreign.domain/windowNameConnection.html
});

connection.request({
    url: https://foregin.domain/apiurl,
    header: {...}
    params: {...},
    success: someSuccessCb
});

Of course the ability to do AJAX requests is purchased by a minor performance loss compared to form posts. BUT: The windowNameProxy should only be seen as a fallback for Browsers which are not capable of the HTML5 workers. Users of these old browsers are obviously not keen on enhanced performance. Otherwise they would use an up to date browser.

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.