Adding a placeholder hidden field onto a smart UI form

HFCDev · 2022-05-20T15:09:17+00:00

There was an error rendering this rich post.

Hi,

I am doing this initially for business WS but ultimately I need this for all create forms in Smart UI. This post is kind of part Smart UI JS, and part Oscript, and this may be difficult to follow.

What I'm trying to get: Any request to create an object, I want to add my own custom ID to the REST POST/PUT that sends data to create the object. This should be a hidden field, not viewable by anyone, but only accessible to any UI elements that I write.

Why I need this: I have an alpaca form extension where I implement some additional UI to get additional information to associate with my category attribute. For the case of Update, I already can save this information easily since the node already exists, and to save my data, I don't need to interact with the form. For the case of a new object, the object doesn't exists yet, so the additional UI needs to write that data to a cache. I want to associate the cache with the create request, which is why I need to get that ID (in this case, a cache ID) into the create request.

What I have so far:

I managed to override the CSNode object, so it includes my custom prototype, called external_emlc_cacheid which I set to a default value of 65530 (just to help me find it when I'm exploring the DOM - I will change it to zero later, and the UI should be able to update this with whatever I get back from LLIAPI.CacheUtils.Add() )

When I go to create a business WS for instance, the form call looks like this:

Even better, if I go to create the business WS, that external cache ID I added to the prototype for the default CSNode Create action is included in the POST REST create call.

So now my big question is how the **** do I access it?

In my alpaca form extension, I have access to the connection object. Here is the source:

In the connector object, I'm able to get to a node object, which in theory should have my external cache ID. When I output to the console, I get this:

As you can see, the external ID I added is missing. I need to access it from my al paca form extension so I can change it when my UI updates additional information in Content Server and sends back where it stored it.

I suspect what this boils down to are these questions:

1) What additional JS or server side plumbing do I need so that the node object I can access from the al paca form field is accessible either to read or to write?

2) How do I go about updating it?

3) If connector.context._factories.node is not the best place to access this data, where is?

4) Is there a better way to do this than overriding the CSNode::NodeActions::Create object to add my own prototype?

Thanks in advance

-Hugh

Find more posts tagged with

Comments

Jan Velas

Hello Hugh,

This is interesting and I would like to help.

Truth is there's not that much I can do, but, ****, I don't see anyone else around here 😅 (- I'd really like for that to change though.)

I can't help with anything sever side, as I have 0 experience with OScript.

I can provide some empirical knowledge about client side stuff and Smart UI SDK. And maybe a little bit of rubber ducking. (https://rubberduckdebugging.com/) 😄

Jan from the future: There is a way.

Also: Looking back, I'm really sorry I made this so long.

Summary

You have a custom field called "external_emlc_cacheid" that you managed to inject into the REST API used for creating business workspaces, both GET and POST (that's awesome, by the way).

The custom field needs to be only displayed by the UI you write.

You struggle to access it because it's not in the NodeModel where all the other fields are.

Missing information

By the way, what version of CS are you using?

How-To

Launching the action - AddConnectedWorkspace Command

This command is the one from the "plus" menu allowing us to create a new BW.

I assume this is the command you are using, but it will work from anywhere.

Just as I click the "plus" icon, Smart UI makes a call to "/api/v1/nodes/<id>/businessworkspacetypes":

This returns the types of BWs that are enabled for this container.

Based on that additional commands are added in the rolled out menu.

When clicked, the "execute" function gets called and the command prepares everything it needs. It then displays the metadata form.

💡 More can be seen at Smart UI SDK path: lib\src\conws\utils\commands\addconws.js

WorkspaceCreateForm Collection

One of the things that the command does, is creating WorkspaceCreateFormCollection and fetching it from the REST API.

This is the object that holds parsed form definitions from the REST API, your custom attribute included.

Smart UI SDK path: lib\src\conws\models\workspacecreateforms.js

As I said before, I can't do anything in OScript, so I took a liberty to inject some data into the response in here so I could replicate your case.

// lib\src\conws\models\workspacecreateforms.js

var WorkspaceCreateFormCollection = NodeFormCollection.extend({
    ...
    parse: function (response) {
        console.log("Parsing response"); // TODO Jave
        ...
        // TODO JaVe - Add dummy data
        forms[0].data.hugh_emlcId = 12345; // forms[0] is the General tab
        console.log(forms); // TODO Jave
        return forms;
    }
});

Thanks to that, the response now looks like this:

I have the emlcId in there, but it's not showing anywhere! I'm exactly where you are now.

We need to extend the view!

We have the data, but the view doesn't know it should display it.

Fortunately, Opentext made it to be extensible! (Thanks, Opentext! 👍️)

You need to have a Smart UI SDK Extension project installed on your CS.

In it, you need to have following in your ...-extensions.json:

// hugh-extensions.json
{
  "csui/models/server.module/server.module.collection": {
    "modules": {
      "greet": {
        "version": "1.0"
      }
    }
  },
  "csui/widgets/metadata/metadata.property.panels": { // <-- This one is not required, it adds new panel
    "extensions": {
      "greet": [
        "greet/widgets/metadata/metadata.property.panels"
      ]
    }
  },
  "csui/widgets/metadata/metadata.general.form.fields": {
    "extensions": {
      "greet": [
        "greet/widgets/metadata/metadata.general.form.fields"
      ]
    }
  }
}

(Mine is based on greet-extensions.json from the SDK)

You also need to copy all the files into your extension project (from the SDK).

In greet\widgets\metadata\general.fields\hello\metadata.general.form.field.controller.js you will find the function. You need to add your field definition there:

// greet\widgets\metadata\general.fields\hello\metadata.general.form.field.controller.js
getGeneralFormFieldsForCreate: function (options) {
    console.log(options); // TODO JaVe
    var fieldModel = new Backbone.Model(helloFieldForm);

    var emlcId = options.forms.at(0).get("data").hugh_emlcId; // get the data from the form collection
    console.log(emlcId);

    var emlcIdModel = new Backbone.Model({
        data: {
            hugh_emlcId: emlcId, // emlcId from the general form from the REST API
        },
        schema: {
            properties: {
                hugh_emlcId: {
                    readonly: true,
                    required: false,
                    title: "",
                    type: "string",
                    hidden: false,
                },
            },
        },
        options: {
            fields: {
                hugh_emlcId: {
                    label: "EMLC ID",
                    hidden: false,
                    readonly: true,
                    hideInitValidationError: false,
                    type: "text",
                },
            },
        },
    });

    return $.Deferred()
        .resolve([
            {
                formModel: fieldModel,
                formView: MetadataHelloGeneralFormFieldView,
            },
            {
                formModel: emlcIdModel,
                formView: MetadataHelloGeneralFormFieldView,
            },
        ])
        .promise();
},

The result

More technical info about MetadataAddItemController

I got really confused about something, so I'm mentioning it here.

Back in the AddConnectedWorkspace Command, there are 2 controllers.

MetadataAddItemController and WorkspaceMetadataController.

AddItemController documentation: lib\src\csui\widgets\metadata\doc\metadata.add.item.controller.md

Smart UI SDK paths:

lib\src\csui\widgets\metadata\metadata.add.item.controller.js

lib\src\conws\models\metadata.controller.js

The one actually displaying the form is MetadataAddItemController, but it uses the WorkspaceMetadataController from the options to actually create things on server!

❗️ This allows the Smart UI to use the generic stuff from the general Add Item view, but have all the custom logic required for creating BWs inside of the WorkspaceMetadataController.

// lib\src\conws\utils\commands\addconws.js = the command from the plus menu

...
options = _.extend(
    {
        formCollection: new WorkspaceCreateFormCollection(undefined, { // <-- This is where the Collection is created and REST API call made, by the way
        metadataAddItemController: metadataAddItemController,
        node: status.container,
        type: subType, //options.addableType
        wsType: wsType,
        template: template,
    }),
    metadataController: new WorkspaceMetadataController(undefined, { // <-- Here is WorkspaceMetadataController
        type: subType,
        wsType: wsType,
        template: template,
        collection: status.collection,
        }),
    },
    options
);
...
// Down below

metadataAddItemController
    .displayForm(status, options) // <-- options created above
    .then(function () {
        ...
    });

and

// lib\src\csui\widgets\metadata\metadata.add.item.controller.js

...
    this.metadataController = options.metadataController; // <-- that's the WorkspaceMetadataController

It's a bit muddy and it really confused me.

There may be no need for the cache

While creating the new BW object, the Smart UI actually creates an empty Node on client side and holds it in memory.

We could maybe fill the stuff in there?

Maybe we can look into it more.

About accessing the data

I ran out of time but I can tell you more about it later, if you want!

In a hurry,

Jan

HFCDev

HI Jan,

Thanks for the response. This does give me more insight. I suspected that the MetadataAddItemController might be something I need to access. I don't actually need to display my custom ID, what I do need, is to be able to change it from a Vue dialog that I load through a control on the browse page.

On the Info page, or on the BW create page (and eventually on the drag and drop fill-in-any-missing-mandatory-metadata page), I have extended the Text field and TextArea Al Paca controls to add additional functionality (currently not showing, but eventually there would be a image or button beside the field. The problem I'm finding is that since my integration point is the field, it doesn't have access to the general form. The following illustrates my scope problem.

However, I think what you are saying is that if I had a form controller extension, it would allow me to add something to the page itself. What I really need is to be able to access it from the al paca field because that's where the control is activated from.

I will go through the controller examples you showed and see if I can make any of this work.

Thanks again

-Hugh

HFCDev

I think I can simplify this down to the following:

* I don't need to see my cache ID - it's something that my own dialog gets. In fact, it's better if it is not seen (except in console.log()).

* The dialog is invoked from the text field on my alpaca form. It can write back to any extension function on my alpaca form field extension

* I think what I need is a way to access the model. I want to access the model so that when I click on Save, it sends whatever ID my dialog was able to get back from the server into the REST request when I go to create the Business WS, so that server side, I can get both the new WS creation data and my cache ID at the same time - this is literally the only way the data can be brought together.

This screenshot of my alpaca field extension illustrates the problem.

In the above, none of the parameters passed have any sort of access to the form outside the category form. How does one go about accessing the model for the entire page (which would include all category forms as well as the general parameters form, where my data can be found)? If this were java/spring, I'd say dependency injection is what I need, but I'm not sure that Backbone has that.

-Hugh

Jan Velas

Good morning Hugh,

I think I get it, you just need to access the REST API data from your custom field. I focused too much on the CS UI.

The real problem is, that your constructor gets called by some lower level (form.view?), and you don't have direct access to the fetched data. Or that the data doesn't get loaded into this form.view together with other attributes. I have an idea.

The right way to go about this is not by reading directly through "connector.config.context._factories".

The "context" in smart UI is actually this one big object that gets shared through all the parts of the app so you can access different parts from anywhere.

Try to get the context object and save it. It's usually under "options.context", but if it's not there then "connector.config.context" should work as it should all reference the same object.

You may be interested in reading "lib\src\csui\utils\contexts\context.md" - it really explains a lot about Smart UI.

I replicated your case more closely by putting console.log(this) into alpcsuitextfield (the one you're extending I think) so we have access to the same stuff.

I'll look into it a bit more today and let you know what I found.

The key is, that the data is stored inside of "WorkspaceCreateFormCollection" - we should be able to get that from the context.

Jan Velas

I found the original collection.

Turns out the "WorkspaceCreateFormCollection" is not shared through the context, but it can be accessed through the formView from the same connector.config.

Here:

this.connector.config.formView.options.displayedModels.at(0).get("data").hugh_emlcId

There should be your data.

Let me know if it works out for you.

Jan

HFCDev

Hi Jan,

This is nearly it!! I am able to get whatever I have as my cache ID that was passed from the server. However, I don't seem to be able to set it. More to the point, whatever I'm setting is not getting sent in the REST request.

In my server override, I set the starting value to 0. I then tried in my form field to change it (using a function in my extension) to 65535. When I click on save, the original value gets sent across, not the one I just changed it to. i.e. 0 not 65535.

I fetched the form object that you pointed out. I created the following function to do that:

where that.models I set in my constructor to connector.config.formView.options.fetchedModels.formCollection.models (an array with 3 elements, the first of which is the General form).

I set my value using the following function:

To verify that I did in fact set my value, I write to the console log the ID just saved there. The function to retrieve the cacheID is as follows:

In the first function, it echos out the form I retrieved from the models array so I can see the value being set to 65535, i.e.

I checked all through that attributes structure. and I don't see any place else where there is my external cache ID set to something other than the value I set, but in the return request, it's unchanged at 0.

I feel like I'm missing a way of setting this, or I need to set this by calling a function on the model itself. I'm just not 100% sure how I get this as a model "object" rather than an associative array.

Thanks in advance

-Hugh

Jan Velas

Hello Hugh, I have some news - I think I finally got it.

What I found out is that the original collection (WorkspaceCreateFormCollection) is only used once; for creating and drawing the form view. It's not used again when modifying the data by users, or sending it to the server. That means we have to look elsewhere yet again.

It's a bit muddy, since there are so many layers, and everything gets shared in obscure ways.

It also doesn't help that the Alpaca framework and Backbone are about as compatible as oil and water.

How-To modify the form via code

Firstly, we have to wait before the form is done rendering.

Why?

Your entry point is the constructor of a form field. At this point the form is not fully created yet and cannot be accessed yet. For the same reason we cannot modify the data before it gets passed down - because by the point your constructor gets called, it's already created copies everywhere.

How to solve it?

We have the access to the FormModel, so, my best attempt is to find an event that gets fired after the form is done rendering.

I found the "render:form" event which seems to work out, but I don't like it...

// inside of your field constructor
var formView = this.connector.config.formView;
var modifyEmlcId = function () {
    // Inspiration gained from lib\src\csui\widgets\metadata\general.panels\node\node.general.form.view.js
    var emlcId = this.$el.alpaca("get").childrenByPropertyId["hugh_emlcId"]; // << this wouldn't exist yet if we didn't wait
    if (emlcId) {
        console.log("EMLCID FOUND");
        emlcId.setValue(555); // This is an alpaca method, it won't update the view
        // TODO - figure out how to refresh the form again now, without causing infinite loop.
    }
};

formView.listenToOnce(formView, "render:form", modifyEmlcId);

... but hey, it works. What follows is the data sent to the server.

I really dislike this solution, but I didn't find anything else that would work in the time I had.

This helped me a lot

This thing really helped to shed some light into the matter:

lib\src\csui\controls\form\doc\form.md

## How to let a field access the form and context objects

The Alpaca field constructor obtains the `connector` object, which can carry

custom configuration passed from the form:

constructor: function MyField(container, data, options, schema,

view, connector, onError) {

this.base(container, data, options, schema, view, connector, onError);

The `connector` object is saved by the base Alpaca constructor to the field

instance and the custom configuration can be accessed `this.connecto.config`.

The following properties added by the `FormView` are available there:

***context***:

The data-managing context passed down by the scenario-owning component;

usually the widget. It is available from the beginning of the constructor

already.

***formView***:

The `FormView`, which owns the field. It is available from the beginning

of the constructor already.

***form***:

The Alpaca form object. It is available after the entire form was rendered. <br />

**Warning:** You cannot access `form` in the constructor and in the `postRender`

callback. It is useful only in field changing event handlers, when the user

interacts with the form.

If you implement the field content using a descendant of `FormFieldView`, you

may need to pass the `context` and/or `formView` to the field view.

The `context` is useful, if the field will makes a CS REST API call.

The `formView` is useful, if the field accesses other fields in the form.

var fieldConfig = this.connector.config,

fieldView = new MyFieldView({

context: fieldConfig.context,

formView: fieldConfig.formView,

model: new Backbone.Model({

data: this.data,

options: this.options,

schema: this.schema

}),

...

});

I'm not really happy about this, the more I dig in it the more I see we're bending something in a way we're not supposed to.

I think the better solution would be to use the controller extension I talked about way up there (greet\widgets\metadata\general.fields\hello\metadata.general.form.field.controller.js) and do the logic in there, as we have full control of the model.

Do note that if the core problem is that the node doesn't exist yet, we actually have full access to it under "this.connector.config.formView.node".

Then again, I don't know if it's possible in your case...

Tell me what you think about it later 😊

Jan

HFCDev

It will take me a little while to go through all of this. I suspect that we won't be putting this into the current release because this has burned way too many hours already, and there is pressure to have a release date.

I may have a node in JS client side, but the whole reason I need it server side is to make changes to tables that have the node ID (server side DB-generated) as the primary key.

What you said about the forms being present only to render the page makes perfect sense. I had a feeling that what I was getting was a read-only copy of the form. I'll have more comments once I get a chance to digest this - was dealing with an elderly parent this weekend.

-Hugh

Jan Velas

Good luck!

It's a shame it's so complicated. It feels like I went on one giant exploring journey and learned just about everything but anything useful to your problem. I got a bit carried away.

But I do believe there is a solution hiding in the framework somewhere.

Jan

HFCDev

Hi,

I am reviving this discussion because I've found workarounds for not being able to edit any values on the general form. However, there are other problems I now have to solve.

In my module, using the same technique that I developed last year, I am able to get my own variable onto the General form. For the sake of this post, let's call it external_cache_id. Instead of setting it to zero and letting something else update it (which I was unable to do), I instead use the GUID drop-in server side to generate a new GUID. I accomplished this by Overriding CSNODE::ObjectsWithPrototypes::Actions::NodeActions::Create

I extended the SetupPrototypes function as follows:

This gets me a random GUID on the general form in my create call, from which I can now access from my control, and using my own REST service, I can save this data to memcache using that GUID as a key.

My problem is that now, despite being on the form, this data never gets sent in the create POST. I suspect I'm missing something somewhere to get the form to send this via REST in the call to CREATE. Can anyone give me a hint at what I'm missing here server side to tell the Smart UI form to send along my external_cache_id in addition to the parent_id and external_modify_date?

Thanks in advance

-Hugh

HFCDev

An addendum to this. I found that my extension above worked on Business Workspaces in that I was able to get my cache ID into the business workspace. Unfortunately, I don't have a way of getting the property into the createInfo assoc that gets sent to the Business workspace creation function in $OTSAPWKSP. In $OTSAPREST, the V2 CreateBusinessWorkspace REST handler sees the parameters including my cache ID, but it copies a very explicit list of parameters to the props local Assoc variable, meaning a wrapping override (where I do my thing then call the original function) won't work - the only thing that would would be to replace the entire function - something that is fraught with pitfalls as OpenText core code changes on a quarterly basis. If anyone from OT development is paying attention, how do 3rd party vendors get their data into the createInfo assoc that gets accessed by any callback from the LLNode.NodeCreate() method?

-Hugh

HFCDev

I have solved the above problem as well!! At least for Business Workspaces. What I was able to do was my external_cache_id param (which got generated when the form fields were requested from CS server prior to rendering), and in the REST2API.CreateBusWorkspace call (server side), I was able to wrap the _ConvertCategories method. The object on which the method is called has all the form data in the .fEnvelope feature, and there was my generated GUID. Using that GUID, I could make a call to the memcache API in $LLIAPI, and get the data that I had previously saved to memcache. For my purposes this works brilliantly, and I'm able to apply my additional data at the time of node creation as required.

The last place I'm stuck is on the case of regular document creation. Normally if you add a document in Smart UI, you get no metadata UI unless there is a mandatory attribute. Then you get a panel to set your metadata after selecting your document. The problem is that although there is an external_cache_id (that I made appear) there in the general form that we talked about earlier (that's how I was able to save my data to cache), it doesn't come across in the REST call. This is the sum total of data that comes across on document create, when there is mandatory attributes (roles decompressed for brevity):

Does anyone know where smart UI gets a list of the fields to pass from the general form in the node create request? It feels like there has to be something server side. For example, here is the create request for the business workspace:

As you can see my external_cache_id made it, as well as a whole bunch of other fields, many of which are in common with document create but not pushed to the server in the REST POST call.

-Hugh