Table of Contents
Widgets define the behavior of all user interfaces rendered within the content and navigation regions of the mobile app. These widgets are formatted in Widget Export Format, the same as generated by Widget Studio in Zimbra Community when exporting a widget.
Multiple widget exports (each potentially containing multiple widgets) can be placed within the
Resources/ folder of the mobile web server components, and they are made available to pages. Additionally, they can also be embedded in other configuration files.
The default set of widgets are contained within the
Resources/Widgets.xml file in the web server components. This file is in widget export format. While the file can be edited directly, embedded attachments are base64-encoded, limiting editability.
If you want to add custom widgets, it's not necessary to edit
Widgets.xml; you can author widgets in Widget Studio in Zimbra Community, export, and drop them into the
When previewing changes, the mobile app/site can be viewed on a mobile device's browser or through the native app (if deployed). There is no need to recycle the web server components.
If you do wish to edit the default
Widgets.xml, or you want to author widgets on the file system, the wdgt tool can assist. wdgt converts widgets from widget export format to factory default format and vice versa.
Factory default format refers to each widget existing in a separate file, with all associated attachments also existing as separate files in a pre-defined structure on the file system.
Where an export format would be a single XML file containing multiple XML-encoded widget source files and base64-encoded attachments, factory default widgets follow the directory structure:
/parent /widget-name.xml /widget-UUID /attachment.extension
cb7d4… refer to the IDs defined by the three widget files.
/parent /19db5de0a1654ea594b3a1540cf3d553 /ui.js /4f1a3378c9f84f129702bef3fab4eefc /ui.js /cb7d40730a64458792894cec206da723 /more.vm /story.vm /stream.vm /ui.js /GroupBanner.xml /BlogPost.xml /ActivityStoryStream.xml
Each factory default widget XML file follows the format:
<scriptedContentFragments> <scriptedContentFragment name="NAME" instanceIdentifier="Identifier_GUID" version="184.108.40.206" isCacheable="true" varyCacheByUser="true" cssClass="CSS_WRAPPER_CLASS_NAME"> <contentScript> <![CDATA[ ## Main widget script, in Velocity ]]> </contentScript> <configuration> <![CDATA[ <propertyGroup id="options"> <property id="maximumTags" dataType="int" defaultValue="25"/> <property id="minimumPostsPerTag" dataType="int" defaultValue="1"/> </propertyGroup> ]]> </configuration> <languageResources> <language key="en-us"> <resource name="RESOURCE_NAME">RESOURCE_VALUE</resource> </language> </languageResources> </scriptedContentFragment> </scriptedContentFragments>
A common development pattern is to develop on the file system in factory default format, storing factory defaults in a source control system. The "build" step is to use wdgt to convert the factory default files into a single widget export format. During development, it's also possible to run wdgt continuously in watch mode, automatically re-compiling factory defaults into an export in the
Resources/ folder on each file save of the defaults.
Example of running
wdgt in watch mode against a directory of factory default-formatted widgets:
wdgt.exe -f export -i SOURCE_DIRECTORY\ -o WEB_ROOT\Resources\MyWidgets.xml -c -w
For more information about
wdgt, please refer to its documentation.