Widgets define the behavior of all user interfaces rendered within the content and navigation regions of Telligent Community Mobile. These widgets are formatted in the Telligent Community Widget Export Format, the same as generated by the widget editor in Telligent 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.
[toc]
Adding and editing widgets
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 the widget editor in Telligent Community, export, and drop them into the Resources/
folder.
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.
Using the wdgt
tool
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
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
For example, 19db5…
, 4f1a3…
, and 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="7.0.0.1" 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>
Useful Patterns
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.