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.
Continue reading
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:
Continue reading
To summarize what we’ve done so far:
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.
Continue reading
In this series of posts, we will learn how to develop and use a new attribute/property editor in your Entry Template layout.
This is not as easy as it first sounds, so I will split this tutorial in 6 parts.
Here is the summary of all parts, they should be taken in order.
It’s good to start with some basic comprehension of how the editor mechanism works in ICN. The most important class is the ecm/model/configuration/ControlRegistry class
Everything starts with this class, this is the main registry storing the configuration of the editors. This consists of:
This is how looks this class:
Continue reading
This is the second post about the issue occurring when using Workplact XT entry template with ICN. We’ve seen that there is an inheritance problem in this post, we will now see that there is a problem of File Types filters. This issue needs to be addressed if you want to use the second work around of the former issue.
You’ve created Entry Templates in Workplace XT, and also created a few File Type Categories gathering several MIME Types. You’ve used these Entry Templates by associating them on a folder to use them when adding document. You restricted them by File Type Category. For example ET 1 is only for Images (File Type Images gathering image/png, image/jpeg, …), ET 2 is only for office documents, and ET3 is for every king of document. That looks a little bit like that in Workplace XT:
Problem is that in ICN, this does not work. You always get the generic entry template (in my case misc doc, or no Entry Template if they all have restrictions on the File Type Categories.
Continue reading
Be careful with the Entry Template, they can have two states, retrieved or not retrieved. They contain a lot less information when they are not retrieved.
Here is how to check if it’s retrieved or not, and retrieve it if you need to:
if (!entryTemplate.isRetrieved) {
// Retrieve it
entryTemplate.retrieveEntryTemplate(lang.hitch(this, function (retrievedEntryTemplate) {
// Do something with retrievedEntryTemplate
}), false, true);
}
Here is the JSDoc of the ecm.model.EntryTemplate class, and the one of the retrieveEntryTemplate function. Actually the entry template object itself is updated so most of the time you won’t have to do anything in the callback except wait for it to happen. Example (function converting to classic callback to promise):
Continue reading
Have you ever changed a File Type filter name in ICN? Well don’t, that’s not pretty. All the associations of Entry Templates you’ve done on folders will just stop working, or at least stop offering the user the right Entry Template for the document’s MIME Type. In the configuration it looks like this:
Explanation is simple. In ICN, apparently there is no ID for File Type filter, or more specifically the name is the ID, which means where you are doing an Entry Template association in ICN, an JSON object is stored as a folder preferences annotation, persisting the File Type filter name directly. Of course if you change the File Type filter name, they won’t look for all folder preferences annotations and change the File Type filter name in it, which means they will all be broken.