Override function in smart view

Options

Hello,

I need to change smart ui function and basically do a very minor change. In particular, i want to change category inheritance for copy/move to always inherit target.

There is a parameter in csui/dialogs/node.picker/impl/header/header.view.js that controls this.

initialize: function () {

...

var defaultApplyPropertiesOption = ApplyPropertiesSelectorView.KEEP_ORIGINAL_PROPERTIES;

Is it possible to somehow override this JS file / function similarly as it is in oscript?

And what would be possible alternative how this could be changed?

Thanks,

Ugis

Comments

  • Hi

    Its not OScript nor its a template based language. Its JS.

    But you can do this:

    Change the header.view.js then

    2 possibilities:

    a. Map your changed header.view.js over the original one

    b. (not really recommended) Go back until you see the first widget. Change all require.js paths to reflect your change. Spawn your top-level widget to reflect all new paths. Add your spawned widget using a perspective.


    I would use the map command.

  • Hi,

    Do you have any hints how to "Map your changed header.view.js over the original one" or any samples somewhere?

    Thanks,

    Ugis

  • I recommend you filing a feature request about it. There is no other way how to make Product Management add or change a feature. If you do not do it, you will be spending your time by looking for workarounds forever.

    The problems with using the RequireJS starMap to force a RequireJS module with a different name loaded instead of the original one are:

    • There is no public interface to set the starMap programmatically, similarly to the config by GetDynamicConfiguration. You could insert the csui.require.config statement into one of your JavaScript bundles as a workaround.
    • You would have to copy the original module source, which means maintenance costs. You could remap the original module too, depend on it in your new module and try using inheritance to override only a part of the original export.

    Another option (and ugly as well) is loading the module which export you want to modify way earlier, than it would get to be used in the application, and modify it. A context plugin is a usual pick of an extension point for this "misuse":

    // inside the module callback, independent on other code
    require(['module-to-change'], function (exported) {
      // modify exported
    })