Forms in a Workflow and Custom Coding

Veronica O · 2021-05-17T17:49:40+00:00

There was an error rendering this rich post.

Hello! I originally posted this in Workflows and Forms but someone suggested I might get more bites here...

Typically my organization displays forms via a workflow using the "Display: Smart View" option for the wf step. However, my current customer would like some custom code added to their form (specifically for one of the date picker fields to auto populate with today's date (well, the present date the form is being filled out on)). To the best of my knowledge, there is no way to custom code in this view. So my two questions are:

Am I correct in assuming there is no way to marry these two options (Display: SmartView and custom coding)?
If I am, is there a way to code a Form View to display in Smart View rather than classic?

Thank you all!

Find more posts tagged with

Forms

Comments

Reiner Merz

You have two options on that:

a. add your custom code in a view and display this through a workflow workitem extension of smartUI. (after having coded that). Dont forget to extract all data necessary in the GetRESTServideData in the wfmain module. This is a slide for how it looks link from my workflow training

b. Try the same thing using a webreport. But this is actually not working, see https://forums.opentext.com/forums/developer/discussion/303904/smartview-workflow-extension

Hope that helps

Reiner

Ferdinand Prantl

I can imagine several possibilities. You could also file a feature request about this. Defaulting to today's date could be added to the OOTB product as an option.

Default in the form schema

Smart UI forms display the default values from the form schema. If you save the default value with the form definition, you will see the field pre-filled. In this case, the form definition would have to support something like %TODAY%, so that the REST API delivering the workflow form would compute the date and return it within the form schema. I do not know, if workflow forms support a placeholder for the current date, or how this could be implemented as an extension in OScript. No change in UI needed.

Default in UI when rendering the field

If the form schema does not contain the default value, the date picker field could be configured to pre-fill the today's date by default. However, it is not supported by the built-in date picker field. You could write a custom field (UI), inheriting from the built-in one and replace the references to the built-in field in the server response. I do not now if workflow forms have a similar hook to massage the response like /forms/nodes/update, for example.

Custom form

It is Reiner's example. You can do whatever you want in your view. You would probably use FormView and populate it with a form schema including your date field. Because you would be able to massage the form schema on the client side, you could compute today's date and set it to the model before the view got rendered. But because you generate the data for the workitem controller on the server side yourself, you put the today's date to the server response already and reduce the work in UI.

David Henshaw

Just some heads up on the custom approach that Reiner mentions and using the Smart View SDK Workitem Extensions Controller.....

A) You'll need to make modifications to the process to compile the Smart View code you produce. You'll need to add some references to the project's gruntfile to include the workflow "bundles" and also to your config-build to add a reference for workflow setting to "empty" so that dependencies aren't traversed and compiled into your outputs (unnecessarily).

B) The "FullView" with the workitem extension (bottom right) of Reiner's screenshot requires you to implement all logic and presentation. i.e. if you need a header to display with details of something like the workflow title, or step title....that becomes your responsibility. Want a footer with action buttons to submit, send on or cancel. Same, you need to implement.

I'm always happy to be corrected here, but the workflow bundles don't seem to expose (publically) a generic or extensible component/control/view handling these aspects.

Reiner Merz

You are right in the sense, that this changes require a workflow type to rely on. You can use the standard type, but then this applies to all workflows of that type. Creating custom workflow types is easy and this is described for example in the OT Training 4-0141 Livelink ECM - Enterprise Server Builder Workflow Customization (former 301)

a. Of course, if you use things from the workflow package, you need to add this to your gruntfile or gulp (dependoing, what you use) and on the config-build. But thats pure handling of the SDK. But: Preemptiv adding of all packages slows down your the speed of your grunt/gulp process quite a lot. I am using different generators already set for different project requirements to simplify that.

b. Of course. But gives you total freedom on building the new Workflow View. You could even introduce something with a futuristic look instead of the old fashioned workflow layout (as example https://medium.com/@pixelcave/building-a-sci-fi-dashboard-in-less-than-4-hrs-44abe5a36a6b )

Last Point: Quote I'm always happy to be corrected here, but the workflow bundles don't seem to expose (publically) a generic or extensible component/control/view handling these aspects. Endquote

Thats not really the case. These extension controllers provide exactly this, although the documentation has lots of space for improvement. But once you understood how this is working (Oscript+SmartUI) you'll find using this thing is very relaxing.

As of now I am upgrading my smartUI Advanced Training for 21.2 (among other chapters also the Workflow chapter which actually consists of 67 slides).

Ferdinand Prantl

Correction: the number of Smart UI dependencies does not affect the performance of the build. I mean the compilation - the production of the output JavaScript and CSS bundles. In a project follows the best practices, of course, as it is ensured by the genearator-csui-extension. For example, from src/config-build.js:

require.config({
  "paths": {
    "myext": "."
    "csui": "empty:",
    "workflow": "empty:",
    ...

Using this configuration, RequireJS will not walk the complete dependency tree. It will walk only your source tree to locate all modules to bundle. It does not matter how many Smart UI components the project will refer to.

If you specify the actual dependency paths instead of the "empty:", for example:

require.config({
  "paths": {
    "myext": "."
    "csui": "../lib/src/csui",
    "workflow": "../lib/src/workflow",
    ...

The build will take unnecessarily longer and you will have to add a module exclusion list to your src/Gruntfile.js to prevent the dependencies from being bundled to your build output.

If you wish to check for mistakes in RequireJS module references like "workflow/does/not/exist", for which you wanted to have the full dependency traversal, you can inlcude the Grunt task requirejsDependencyCheck instead, which runs faster and checks also that all dependencies refer to public modules.

Unit tests and test pages will load slower, when you include more dependencies, of course, just like the productive pages will.

Reiner Merz

ok one aspect. BUT: with several other packages, you'LL have to add the packages component.js to your csuiComponent. And this slows down the build process.

csuiComponent = require('../lib/src/csui/component'),

is much longer including the other modulke component.js files. Loading and initialializing will take quite some time.