More Updates to the List Quick Helper

Again I’ve put some focus on the List Quick Helper which I think is a valuable extension on its on but also is a good platform for further extensibility. Extensibility not necessarily created by myself.

With this update to the helper I’ve included two major additions to functionality.

The Tool Base

Already from the first version of the Helper I implemented several tools to accompany the useful information the helper exposes. These tools are represented using the buttons at the bottom of the helper:

Quick reminder, these tools are:

1. Rename – quickly rename an item without having to open its editing dialog.
2. Goto – quickly navigate to an item using its TCM URI
3. Quick Folder / SG – quickly create a new folder or structure group by supplying the title (and directory) alone.
4. Batch publish – batch items to be published at once regardless of where they are stored in a publication.

Up until now the tools’ code was embedded into the Helper’s script so separating them would not have been an easy task. With the previous version I’ve made it possible to disable the tools using the Extensions Manager configuration interface.

This time I finally got to achieve something I wanted to do already from the start which is to completely separate the tools from the helper’s implementation so its first, very easy to remove a tool if needed and secondly, and mainly to allow the creation of new tools without any changes to the existing code.

Now this is the case, all of the existing tools are implemented as individual objects and can easily be added and removed simply by modifying the extension resource’s XML configuration:

As you can see in the configuration snapshot above, each tool is now implemented in its own JS file.

In order to implement a tool you will need to inherit from a base class I include with the helper called: Extensions.ListQuickHelper.ToolBase.

To do that in your Javascript file you will need to add some specific lines to the constructor of your tool class:

Type.registerNamespace(“Extensions.ListQuickHelper.Tools”);

Extensions.ListQuickHelper.Tools.NewTool = function Tools$NewTool()
{
Tridion.OO.enableInterface(this, “Extensions.ListQuickHelper.Tools.NewTool”);
this.addInterface(“Extensions.ListQuickHelper.ToolBase”, ["NewTool"]);

//additional code for the constructor goes here…
}

Following the OO conventions of the GUI framework, you use the “addInterface” method to implement the ToolBase class and using the second parameter you specify the name of the tool. Its important to do that and choose a unique name.

There are a few methods you will need to override in your implementation of a tool. These are:

initialize – In this method you call this._setEngine passing the engine object which is passed to the initialize method. You can also register your tool’s configuration values with the Extensions Manager using the this._addConfigField method.

show – This method is called whenever the helper is shown, typically when an item has been selected in the list view, you can implement your logic to decide whether to show the tool’s button or not. You can use the props object passed to the show method which has the following properties: ItemType, ItemId, ParentType, ParentId, IsMulti.

_helperHtmlLoaded – This method is called when the helper’s engine loads the HTML for the helper interface.  this is the point in which you should load the HTML for your tool. For that there are two methods available on the base class: _registerToolHtmlFromUrl or _registerToolHtml, the former accepting a URL of a server page containing the needed HTML, the  latter accepting a HTML string literal.

If your tool requires a button, which in most cases it will, you should at this point also call the _registerToolButton method which accepts a few parameters: Title, Id, path to image, function to handle click event and lastly, the position (0 based) in which to insert the button.

This is how a basic handler will look like:

Extensions.ListQuickHelper.Tools.NewTool.prototype._helperHtmlLoaded = function ()
{
var p = this.properties;
var context = this;
var html = this._registerToolHtmlFromUrl($extUtils.expandPath(“/client/commands/ListQuickHelper/Tools/lqhTool_NewTool.aspx”));this._registerToolButton(“New Tool”, “helperToolNewTool”,
$extUtils.expandPath(“/client/commands/ListQuickHelper/styles/icons/newtool.png”),
function (props) { //handle click event
}, 2);};

After defining your class don’t forget to add the following line to the end of your JS file:

$lqht.registerTool(Extensions.ListQuickHelper.Tools.NewTool);

Without it the tool will not be added to the helper.

There are few more methods on the base class which may be quite useful, you can have a look at the 5 tools that come with the helper for some concrete examples. Now some of you may say; “5 tools? but you only listed 4 earlier!” To this I say: You are absolutely correct in your arithmetic objection as this brings us to the next topic:

The Project Info Tool

A few weeks ago, Frank (@puf) ran an idea by me: wouldn’t it be nice to have a similar feature in Tridion to the “readme” reader in Github:

Github relies on the file name (“readme.textile”), if it finds one it will simply show its content on the project page so the creator of the project can add some information there. This is a very handy feature and one that can also translate very nicely to Tridion so a folder or structure group can define its own “readme” text to show some useful information to editors or explain the purpose of the organizational item.

Frank had the idea of implementing this on top of the List Quick Helper which I immediately liked (unsurprisingly). So I’ve set to work on this little feature and this is the result:

As you can see, the information is loaded into the helper’s interface beneath the typical information about the selected item. The information is retrieved from the metadata of the folder in this case but can easily be found on a Structure Group as well.

When minimized the project info becomes another button in the tools bar:

I’ve implemented this feature as another tool(the 5th tool) which was fairly easy to do after building the ToolBase. This tool does require the Extensions Manager as it depends on some configuration:

The first option is whether to look for and show the project info, default is “no”. The second field is whether to continue looking for project info in a parent org item when none is found in the current parent, default is “no”. When this is enabled, the tool will continue to look for the info up to and including the current publication.
The third field is the name of the metadata field that will contain the actual text for the info. This field can be included in any metadata schema that is attached to an organizational item such as a folder, structure group or publication.

Frank and I are looking forward to see how the community receives this new feature and how it will make use of it.

download

The new version of the helper with these new features can be downloaded here.

On a Sad Note…

With a sad heart Im finishing this post as this may be the last one I write about Tridion, at least for the foreseeable future and at least on the more technical side of things.

August is going to be my last month working for SDL Tridion. I will be moving to new challenges soon. Hopefully these will give me enough chances to continue blogging about programming and technology which I very much like to do. Unfortunately, building GUI extensions will probably not get a primary spot in my life from now on.