Menu
  • InShare PlusOne
  • Working with and Customizing the v8.6 Editor

    [The following is a guest blog post from Andrew Eddy, Lead Editor Engineer, Ektron]

    With the release of 8.6, Ektron has incorporated an editing tool that is tightly coupled with our editing experience after installation. After enabling the provider your content authors will have a much smoother HTML5 editing experience, and your developers should have an incredibly easy time customizing the experience for your content authors via plugins that are easy to write and maintain.

     

    Ektron 8.6 introduced many cool new features that enhance its editing experience and streamline content authoring including the inspector, edit in context, view source, templating, validator, etc. At the heart of these buttons within the new toolbar are plugins.

    Each one is open source and easily customizable, powered by an easy to use architecture and code structure using JavaScript and CSS. As a developer (at least for me), there's no faster way to get my hands dirty than to look at the examples and try to extend current functionality to match my content author's needs.

    The following assumes you have of installed the v8.6 Editor Provider within your Ektron instance. Once you've done this, Let's start by taking a look at the plugin architecture for our Editor by navigating to:

    \Workarea\ FrameworkUI\js\Ektron\ Controls\EktronUI \Editor\Aloha\plugins\ ektron\sourceview\lib\sourceview-plugin.js

    You should see the following tree:

    I've highlighted the 'Ektron' subdirectory of the plugins folder above because this is where we did the majority of our work, and where you'll be doing the majority of your editing/creation. Each directory below 'Ektron' represents a plugin. All of your plugins code will be located within its respective directory and follow the following sub directory structure, let's take a look at source view for example.

    Starting with the sourceview directory as the 'PluginName' we have the following hierarchy:

    •  
    • PluginName
    •  
      •    
      • Css
      •    
        •      
        • PluginName.css (Main css file for plugin)
        •    
           
      • Lib
      •    
        •      
        • PluginName-plugin.js (Main JS file for plugin/JS file initially called)
        •    
         

    It really is as simple and organized as it looks! Now to understand the basic structure of the code for the plugin, feel free to open up sourceview-plugin.js or any other of the plugin's main JS file and you'll see they all have a lot in common and follow a very similar outline:

    •  
    • Define/inclusion calls at the top (powered by RequireJS for easy to use paths)
    •  
    • Main function (returns created plugin)    
      •      
      • Defaults (default variables or strings to be used)
      •      
      • Init (function that executes upon load, usually to create the button)
      •      
      • createButtons (function that adds a button to floating menu)
      •      
      • (function that can be called whatever you'd like, and should be executed upon button click)
      •    
       

    Here's the code that will insert a "Hello World!" snip-it within a span tag:

    So now in less than 100 lines, we have a button being added to our toolbar, an action performing when the button is clicked, and logic detecting where you are in the document and inserting an html tag with content as well as a CSS class defined within our supporting css/plugin.css file. That's some pretty relevant functionality for all your developers and system admins that are looking to streamline operations for your customers and users.

    I hope at this point your imagination is starting to run wild a little bit, because it isn't just about inserting content (we made a template plugin that does this for you already!). Take a look at some of our other plugins that are more complex such as the inspector (allows you to apply styles/attributes to any html tag) or validator (pops up a modal window and passes content to be verified via html5, xhtml, and w3c) and immediately you will see the versatility and usefulness of our new architecture. With all this in mind, it's our goal that you'll now be able to quickly and powerfully fulfill your customer requests for editing when before you thought your hands were tied with closed technologies.

    But that's not all! If you do create your own plugin or don't like which plugins are available to your users, that's all customizable too. In the root of your site there's a file called ektron.cms.framework.ui.config . On line #56 there's a section that looks like the following:

    The above structure calls out 10 different content editing scenarios, while the 'name' key is set in stone (you can add additional ones), the path is yours to modify and is a comma delimited string of plugins that follow the plugin directory and name structure with a / separating them. Don't want your users able to enter templates in library descriptions? Feel free to remove 'ektron/template' from that line and it'll be gone!

    With this new easy to use plugin architecture and functionality at your and your customers' finger tips you'll be creating plugins cutting down time and effort for all your content authors.

    Please post any comments below or in our dev center. Plugins too if you're looking to show off!

  • InShare PlusOne
  • Bill Cava
    By Bill Cava
    Twitter: @billcava
    Wednesday, July 11, 2012
  • comments powered by Disqus