Since we introduced the new widget editor and developer mode about a week ago, we've gotten some good internal and public feedback. We wanted to identify a few key changes to this functionality that resulted from that feedback.
Telligent Community 9.0 introduces the ability for plugins to render text using widgets. Most of the new management user experience is implemented this way. Each widget defined by a plugin can be enabled for editing and, in developer mode, all local-developer widgets are enabled for editing regardless of the plugin's configuration for the widget. Seeing front UI (traditional) widgets and plugin-defined widgets in a single list within the widget editor was confusing (especially in developer mode in preview 3). To better separate front-UI-targeted- from plugin-defined- widgets, the list and filters within the widget editor have changed.
Now, by default, only front UI widgets will be shown in the widget editor. The first filter within the editor will be changed to provide options to view:
This makes it much easier to find widgets associated to specific functionality while also uncluttering the filter when working within developer mode.
Factory default widgets are used to provide the "out of the box" experience for core Telligent Community functionality as well as the base experience for 3rd party developers that wish to redistribute their extensions to the Telligent Community platform. Prior to the introduction of developer mode, the definition of factory default implementations required direct text file editing. Developer Mode is intended for developers to manage their factory default widgets using the widget editor within Telligent Community to make development, previewing, and integration with source control systems easier.
Preview 3 enabled factory default editing for all factory defaults, not just the factory defaults owned by the local developer. A problem could occur if a developer edited a factory default that had a deployment process that may conflict with the deployment process of the developer. Specifically, core Telligent Community widgets are installed from embedded resources in the Telligent Community assemblies. Any edits to these factory default widgets by 3rd party developers could be overwritten by the platform installation process.
To prevent this issue and better clarify developer mode as a tool for developers to manage their own factory default widgets, now only widgets that are defined via factory default widget providers within assemblies compiled in debug mode are available for direct saving (as a factory default). This will prevent developers from accidentally editing a factory default widget associated to a deployment process that may cause the local developer's edits to be overwritten.
Additionally, developer mode should never be enabled in a production environment. By editing factory default implementations of widgets in production, a site will have no available backup of the source implementation to revert to when edits introduce breaking bugs. To help prevent developer mode from being enabled in production sites, the developer mode enablement flag in web.config is now ignored if the active license is identified as a production license.
There has been some confusion about best practices for promoting changes from development to QA/production environments. We'll be working on more complete developer training documentation soon, but, in the meantime, I'd like to highlight a few general notes:
Because factory default widgets, whether part of a plugin to implement custom UI or just for the benefit of source control when managing front-UI widgets, requires the implementation of a plugin, we recommend deploying widget files using an IInstallablePlugin (see the 8.5 example here). In 9.0, the recommendation remains to use an IInstallablePlugin, however, the widget files themselves can be edited within the platform widget editor and the installation process can make use of the Telligent.Evolution.Extensibility.UI.Version1.ContentFragments.UpdateScriptedContentFragments() API to automatically version and provide a review workflow for upgrades.
The UpdateScriptedContentFragments() API enables widget files, either embedded or deployed alongside an assembly, to be installed using the same process used by the platform for upgrades. This process automates:
This approach enables the deployment of updates (widgets and code) to a single or multiple customers by copying the release-built DLL into the production environment web and job server nodes without installation steps specific to individual file storage mechanisms. We'll have a complete example of implementing a deployment of factory default widgets using this technique soon after Telligent Community 9.0 is released.
Other customizations should be limited to theme and page edits. Telligent Community 9.0 has improved support for migrating changes to a theme. Within each theme type and context, all changes can be exported as a single file. When importing into a QA or production environment, there are a few changes to note in version 9.0:
Note: Automating the deployment of customizations in bulk or group layouts requires a custom deployment process that is dependent on synchronizing databases and files between multiple environments -- this type of automation is environment specific and is not handled directly by the platform.
We've also incorporated improvements to the widget editor's user interface, including:
I hope that you've had a changes to install and try Telligent Community 9.0 Preview 3. If you have questions, please ask them in the preview forum.