Open generation object on the classic view

Houssem CHAABANI

Hello team,

I know that opening the generation object is not yet supported on the 16.0.3. Perhaps it will be supported on the 16.2. But the client wan't to migrate to this version right now.

Overriding the [getDefaultActionNodeUrl] on the ['csui/behaviors/default.action/default.action.behavior] is it a good idea ?

Thanks a lot

Ferdinand Prantl

As you suspected, opening and downloading the content of Generations in Smart UI is supported in the upcoming CS 16.2.

If you monkey-patch getDefaultActionNodeUrl, you can change the URL, which is rendered on hyperlinks, but not the action, which takes place, when you click on them. (The hyperlink URL is meant to be used for right-mouse-click actions: creating a bookmark, sending by e-mail or opening in a new window. This URL opens a perspective specific for the node. The left-mouse-click executes default action for the context, where the hyperlink is. It can be different from opening the node's perspective (/app/nodes/{node_id}), and for documents it tries to open the content, for example.)

The default (Metadata) perspective, which opens on the Generation URL, does not offer the most useful functionality, but before taking care of that, you would want to override the left-mouse-click for generation - and actually make the Generation clickable at all:

1. Create a command, which can open it. The built-in 'Open' command cannot. You could try to reuse it, after "massaging" the Generation model a little, so that it appears like a document.
2. Create an extension for csui/utils/defaultactionitems, in which you assign your command as the default action for the subtype 2 (Generation).

Customers, who want to use Smart UI, should adopt the strategy of often upgrades. Smart UI is not mature yet and features are delived in quarterly updates for the latest version. If the customer wants to stay with one particular version for a longer time, they would have to use the out-of-the-box functionality only, or build only on the extensibility, which was available at the time of the release. They pay maintenance fee, so that they gain access to the laterst releases and support. If they request backporting of features to earlier releases from OT partners or GS, it will cost them extra money. Also, extension points for the customization may not be available in the earlier version, which would make the customization either impossible, or depending on private code and thus getting broken in the next update. I recommend the customer spend the money on allowing more often the upgrades in their company, and pay for customizations only for features, which will not be provided by OpenText.

Note: I am not a big friend of monkey-patching, because you would need to misuse some extension point, which gets loaded early enough by chance, to get an access to the target object. Also, it makes less clear, why some behaviour has been achieved. It is a fragile customizaton, but as long as you keep to the public interface, it should not get broken. We should introduce extensibility for the getDefaultActionNodeUrl in this particular case.