Sometimes, we want to use a custom property to decide if an action should be displayed, enabled or hidden. The items provided by ICN as parameters of these functions are items as they are shown in the view, as rows. They don’t have all properties fetched, only the system ones and the ones you configured to be shown as extra columns (since they have to be fetched in order to be displayed).
As you may have noticed when overriding the isVisible and isEnabled functions, they are synchronous and they expect an immediate return. That means fetching the attributes using the item.retrieveAttributes function won’t work since it’s an asynchronous function (there is one round trip made to the ICN server to fetch them).
In this post, we’ve seen how to fetch custom attributes for all rows without showing them in a column. We will now see another way to do this, by making the ContextMenu actually asynchronous. Since the isVisible and isEnabled functions are synchronous, we will actually retrieve the attributes before showing the Context Menu for the item.
This post explains how to fetch a custom property you’ve added on a class for all documents retrieved by ICN, before all attributes are actually retrieved using the ContentItem.retrieveAttributes function. That means all items when displayed as row in the Content List view will have this property (also named attribute in ICN) already fetched. There are use cases for this, two of them being:
- Using a custom attribute in the isVisible or isEnable function of an action, to decide if the action should be displayed based on business logic. I wrote about this here
- Using a custom property to display a new icon along with the lock/compound/readon-only/… icons. I wrote about this here
After spending some time investigating how ICN works to know what custom properties to fetch when retrieving the content of a folder (openFolder action), I came to the conclusion it goes through two steps:
Last part of this tutorial will be about enhancing our editor to make it a bit nicer. The idea is to create a property editor to select a file within the repository. We will use the DocumentSelector dialog we wrote here.
We are actually really close of achieving this, we will just hook up the click event of the input field to start the DocumentSelector dialog, and we will also add a Browse button on the right of the input to make it more user-friendly.
This tutorial will explain how to write a dialog allowing users to choose a file in a repository with a pretty tree selector. We will also add a feature to filter files based on extension. The tree will only show documents ending with a valid filter.
This is the final result:
I just noticed a bug in the FolderTree widget. It is setting its size based on the first ancestor widget, not parent dom node. That means if your FolderTree is in a div or anything not widget, it will take the size of the first ancestor widget, which can be a lot bigger than the dom element it is in and give you some weird behavior.
To fix this, wrap it in a BorderContainer, ContentPane or any sort of widget, or override the resize method to behave nicely with your configuration.
Add custom settings to your editor
We learned in previous parts how property editors work, how to write a custom editor, a widget for the editor, and how to test it.
In this part, we will learn how to add custom settings to your editor, located right below the editor select box in the Entry Template Designer tool. It looks like this: (remember, in our current version there is nothing)
Settings are part of the the editorConfig you are injecting in the ControlRegistry object (ControlRegistry.editors.editorConfigs array). The config can have a settings property, which is an array of object defining the settings. Here is how it looks like:
To summarize what we’ve done so far:
- In part 1, we created a new plugin and learned how to inject a custom editor in the ICN configuration
- In part 2, we wrote our custom editor
- In part 3, we wrote our custom widget
We will now deploy the plugin and use our custom editor in an entry template. Then we will add a new document using this entry template, and we should see our custom editor in used.