Zimlet Developers Guide:Developing Zimlets

Revision as of 20:49, 21 December 2009 by Sposetti (talk | contribs) (Internationalizing Zimlets)

Zdg-6-menu-icon-zimbra.jpg Introduction Zdg-6-menu-icon-green-flag.png Getting Started Zdg-6-menu-icon-terminal.png Dev Environment Setup Zdg-6-menu-icon-gear.png
Developing Zimlets
Proxy Servlet Setup
Firefox and Firebug
Troubleshooting
Zdg-6-menu-icon-library.jpg API Specifications Zdg-6-menu-icon-checkbox.jpg Example Zimlets


Zimlet Files

This section describes the various resources and files that are part of a zimlet. A zimlet can include minimally an XML Zimlet Definition File (e.g. com_zimbra_test.xml). This is where zimlet information such as name and version are described.

File Required / Optional Description
{zimlet-name}.xml Required This is the Zimlet Definition file and specifies the zimlet behavior. This file is required for all zimlets. See Zimlet Definition File Reference for more information on the zimlet XML elements.
*.js Optional Supporting JavaScript (JS) files.
*.jsp Optional Supporting JSP files.
*.css Optional Supporting CSS files.
{zimlet-name}.properties Optional The resource properties for the zimlet. These resources are used for internationalizing and localizing zimlets. See Internationalizing Zimlets for more information.
config_template.xml Optional This is the Zimlet Configuration File and is is used to configure zimlet properties, such as "allowedDomains". See Zimlet Configuration File for more information. See Proxy Servlet Setup for more information on allowed domains.

Zimlet APIs

There are different API components in zimlet development. Based on the functionality you are trying to achieve, your zimlet implementation might leverage a combination of APIs.

XML API The XML API is comprised of two components:

You can accomplish a lot with just the Definition File. For example, you can implement content zimlets, build context menus, make your zimlet appear as a panel items and in general, accomplish basic interactions with external services (via the <actionUrl> tag). But there are limits to how much customization and interaction with the Zimbra Web Client your zimlet can have. Also, there is limited debugging. For any zimlet that wants to present custom dialog boxes or advanced interactions with the Zimbra Web Client (e.g. inject buttons, make a zimlet application tab) That's when you start to leverage the JavaScript API with the XML API. All zimlets will, at minimum, have to include a basic Definition File. See the Zimlet Definition File Reference for more information on the zimlet XML elements and syntax.

JavaScript API Zimlets are primarily written in JavaScript. Using the JavaScript API together with the XML API allows you to write really powerful zimlets. You can use the XML API for certain purposes (like creating a panel item, context-menus, etc) and use the JavaScript API to react to events from those items. See JavaScript APIs for more information.
SOAP API Zimbra exposes a SOAP (Simple Object Access Protocol) API to interact with the zimbra server. Using SOAP and XML, data is sent to/from the server to perform server functions on a given mailbox (for example, creating a message or folder).

A more detailed description of the SOAP API can be found in the server source at ZimbraServer/docs/soap.txt.

XML APIs

Zimlet Definition File

This file defines the zimlet and is required for all zimlets. You can implement zimlet functionality directly in this file. It exposes very basic functionality and useful for simple content zimlets (e.g. you can define menu items, the zimlet panel interactions and simple URL actions). But beyond the basic, you will want to leverage the JavaScript API and the Zimlet Handler Object.

See Zimlet Definition File Reference for more information on the zimlet XML elements and syntax.

Zimlet Configuration File

The configuration file (config_template.xml) specifies properties for the zimlet configuration. Properties can be global or host specific. The properties may be accessed within the Zimlet Definition File using the "${}" syntax.

Property Syntax Example
To access global properties ${config.global.propertyName} To access a global property named "defaultToGoogle", the syntax is ${config.global.defaultToGoogle}.
To access host-specific properties ${config.host.propertyName} To access a host-specific property named "googleApi", the syntax is ${config.host.googleApi}.

Configuration properties are also available from the Zimlet Handler Object using the getConfigProperty() method.

See Zimlet Configuration File Reference for more information on the zimlet XML elements and syntax.

JavaScript APIs

Zimlet Handler Object

The Zimlet framework provides the Zimlet JavaScript base class: the Zimbra Handler Object. This class is ZmZimletBase. Developers wishing to implement Zimlet functionality in JavaScript should extend the ZmZimletBase class. The ZmZimletBase contains methods for panel zimlets, tab zimlets and content zimlets.

A recommended naming convention is to use your zimlet name in the name of your Zimlet Handler Object implementation.

Example:

Zimlet Name com_zimbra_helloworld
Zimlet Definition File Name com_zimbra_helloworld.xml
Zimlet Package Name com_zimbra_helloworld.zip
Zimlet JavaScript File com_zimbra_helloworld.js
Zimlet Handler Object name com_zimbra_helloworldHandlerObject

As part of your zimlet, in the Zimlet Definition File, include the JavaScript file:

<include>com_zimbra_helloworld.js</include>

Define your Handler Object in the Zimlet Definition File:

<handlerObject>com_zimbra_helloworldHandlerObject</handlerObject>

To implement the Zimlet Handler Object, designate your handler object to be a sub-class of the ZmZimletBase class in the zimlet JavaScript file.

/**
 * Defines the Zimlet handler class.
 */
function com_zimbra_helloworldHandlerObject() {
}

/**
 * Makes the Zimlet class a subclass of ZmZimletBase.
 */
com_zimbra_helloworldHandlerObject.prototype = new ZmZimletBase();
com_zimbra_helloworldHandlerObject.prototype.constructor = com_zimbra_helloworldHandlerObject;

See Zimlet API Specifications for information on the JavaScript API and the Zimlet Definition File syntax.

Development Mode

When the Zimbra web client is loaded, the server consolidates (i.e. ZIPs) and obfuscates (i.e. unformats) all the JavaScript code in the application. This is to speed login and load time. Additionally, not all modules (for example, calendar, documents, etc) are loaded on initial login and modules are only loaded when needed (i.e. "lazy" loading). The combination of the consolidation, obfuscation and lazy loading makes it difficult to debug code in the browser. For example, a zimlet function like sendMail(param1,param2) in the Zimlet JavaScript file might become hy(p1,p2) in the Zimlets-nodev_all.js file.

For development and debugging, you can disable these activities and run the web client in "Development Mode" by appending a dev=1 to the client URL.

In this mode, all of the web client modules are loaded at login, all of the JavaScript is left un-consolidated and readable. Additionally, to further help with debugging, a debug-window pop-up is opened that shows all of the SOAP transactions as they occur between the web client browser and the server.

For example, append dev=1 to the client URL:

http://localhost:7633/Zimbra/desktop/login.jsp?at=4343c072e-8f566-4af9-8acb-1656046bd230f&dev=1

Note: When you are developing zimlets with Development Mode ON, you should be sure to test your Zimlet with in regular mode (i.e. without &dev=1) to confirm the zimlet works properly. In some cases, your zimlet might depend modules being lazy loaded and you will have to write code to load the necessary modules.

Internationalization

Internationalization is the process of designing a zimlet so that it can be adapted to various languages and regions without code changes. Sometimes the term internationalization is abbreviated as i18n (because there are 18 letters between the first "i" and the last "n").

To internationalize your zimlets, you can include .properties files with your zimlet. These files will include the internationalized text resources used in your zimlet. You can include multiple properties files with your zimlet to support multiple locales.

Note: A locale is the combination of a language code and a country code. For example, the locale for the English language in the country of US is en_US. Or the locale for the English language in the country of United Kingdom is en_GB

A list of locale country codes are at http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm

Properties File Naming Convention

The properties file must start with your zimlet name, followed by the locale and the .properties extension. These files must be in the base directory of your zimlet. The default locale for a zimlet is en_US ("English-US"). The base zimlet properties file is assumed to be English-US and will not include a locale in the name.

For example, a zimlet named "com_zimbra_helloworld" could have the following properties files:

File Locale Language Locale Country Description
com_zimbra_helloworld.properties en US The default properties resource bundle for the zimlet in the en_US default locale ("Language: English, Country: US")
com_zimbra_helloworld_en_GB.properties en GB The properties resource bundle for the zimlet in the en_GB locale ("Language: English, Country: United Kingdom")


Properties File Syntax

The

Tab Zimlets Life Cycle

You can create zimlets as application tabs. After creating your application (using ZmZimletBase.createApp()), you zimlet handler object will receive application events such as ZmZimletBase.appActive() and ZmZimletBase.appLaunch().

Zcs-6-tab-zimlet-lifecycle.png

Jump to: navigation, search