• Using and configuring is mostly intuitive.
• Managing translation groups does not depend on the service.
• The tx command line client eases translation management a lot.

I assembled some documentation in our wiki. Translating for Tine 2.0 is really easy now. If you are familiar with a unix console, also have a look at the command line tools, its really handy and powerful. As we have the .tx configuration in our repo now, you can just start the tine20 directory of your git clone with tx push / tx pull -l <your lang>

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!

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.