What javascript UI framework works best with Content Server Workflows

There are so many javascript ui frameworks in the world: React, Angular, Vue, on and on. I do quite a bit of CS workflow map development, creating views for workflow steps, collecting/validating/storing user input, triggering task disposition, etc. I suppose Rest API will become the core channel for most interactions, WebReport can be used as the view display.

Just wondering, has anyone tried any of the JS UI frameworks above within CS to build small to medium size apps? Which works best?

Find more posts tagged with

WebReport

Workflow Service

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

GregPetti

We have built an entire UI for Content Server (with easy handoffs to Classic and SmartView) using VUE (just upgraded to VUE3). This allows us to deploy a variety of features and in fact it provides a unique IDE for WebReports development and support (among many other things - including some Workflow specific features). That said, we have other products that are just developed using raw HTML and JavaScript within the existing Classic interface, and we have another product that extends the existing SmartView interface for developers. My point (besides taking a moment to talk about our products :-) ) is that there is no one perfect approach. You can build a full blown-unique UI as we have done and benefit from all of the great, robust, powerful functionality that CS provides below the surface. I think we had a video on how to build something like this at some point, but I can say that we tend to use WebReports to serve our VUE client. We could use REST requests, but many of the specialized, proprietary functions we provide do not exist in the REST API. Also some REST request do more than we need, or less than we need, resulting in extra complexity, and or lower performance. What we do instead, is to create WebReports that can access CS functionality through the TAG/Sub-tag interface. We get whatever information we need, fine tuned to our exact purpose, and then we have the WebReport return data in a pre-defined JSON format. Our client is designed to expect this JSON format. So as an example, you might click on a menu option in the VUE client, it sends a request (could be REST or Classic) to run a WebReport, the WebReport could perform a task, and then send back a JSON response something like this:

{"error":false,"data":"your action was successully completed, 10 items updated.","errorMsg":""}

The client code is designed to parse this and maybe pop up a message that shows the response.

I should add that we have created this VUE framework to be reusable for all of our products by defining the schema that it uses and expects.

Cheers

Greg

All comments

GregPetti

deleted duplicate entry.

GregPetti

{"error":false,"data":"your action was successully completed, 10 items updated.","errorMsg":""}

The client code is designed to parse this and maybe pop up a message that shows the response.

I should add that we have created this VUE framework to be reusable for all of our products by defining the schema that it uses and expects.

Cheers

Greg

GregPetti

example of VUE3 client examining a Content Server object:

haoest

looks super nice, thanks for showing your work!

GregPetti

Thanks. This slide basically explains the approach we're using

We use a WebReport to act as the starting page for the applications. As this is a content server object it can be launched in a variety of ways from classic or SmartView - even being wired into classic menus using ActiveView. This application appears like a separate client app but of course it is running directly in Content Server and benefits from all of the features and functionality that Content Server provides.
This main WebReport includes:
- Basic HTML (in particular a DIV the client can attach to)
- JavaScript libraries to load (and in our case the VUE client is loaded here)
- This WebReports also define a JavaScript object (in JSON form) that defines all of the initial endpoints that the client has access to. In our case we are primarily using WebReports as endpoints, though OOTB REST requests could also be used where appropriate. The endpoints are typically URLs that are easily created using WebReport tags (constants) to point to the correct objects on each system where this is installed. The WebReport URLs could be classic format or REST requests.
- When the VUE client loads, it can immediately call some of these WebReports to populate menus, settings etc. These WebReports return JSON structures in a form that is understood by the client.
- The menu options, in turn, include URLS or identifiers that are used to call other WebReports when an option is selected. In this way, everything that loads and every menu or option provided to the client provides the correct end points.

As I mentioned before, we built the client in a way that we can keep extending features by modifying menu options in the existing WebReports to call new WebReports, and these WebReports know what to expect in requests from the client, and what how to format a JSON response that the client can react to. Most of the time, we don't have to add new client features.

haoest

this is absolutely inspiring. totally hack the **** out of webreport. But question, if you have so many WR, how do you keep the relationship, especially on migration to another environment? A long list of Constants?

GregPetti

Well to be clear, we deliver all of our products using the built-in Application Management functionality in Content Server. If you use constants (best practice) to reference any WebReports, then this "CSAPPS" functionality will re-connect all the IDs when you install on another system. If you use constants then Transport, or GCI Power Tools Deployment, will also work fine. You simply define constants for each WebReport and when these tools export, they keep a list automatically. Of course there are other ways to manage the WebReports. You could assign each WebReport a nickname, as long as it is unique for the whole system. The Application Management software also allows you to define a nickname that only has to be unique within a given application. The one thing we advise against is using hardcoded, literal dataIds. The tool I showed you in the screen shot actually runs audits to look for any hard coded identifiers that could break on transfer to another system (including server references and URL parts).

I don't really consider this a hack. WebReports are explicitly designed to let you implement unique server side functionality, with a safe, supported API to access Content Server functionality. In other systems, they do something similar to Python, PHP, Java, Django, etc. albeit with a different syntax. Most developers use the "templating" type approach similar to Blade and Jinja used by PHP and Python, but you could also use scripting. Traditionally in the days before AJAX was prominent, the WebReports were just used to return HTML, and JavaScript to run in the browser with every request, but actually the WebReport is mostly agnostic about what content it sends to the client so with the advent of AJAX and JSON etc. it is fairly ideal for forming data messages. There are a few sub-tags that build JSON automatically with a predefined schema, but the templating paradigm allows you to create your own unique JSON objects, laid out visually and and you simply insert tags to specify the values you need. This can also be done with a more scripted approach too and we actually have a sub-tag that can be used to build JSON structures without worrying about proper closures, commas etc.

I think I've gone beyond my quota for posts this week :-)

Always happy to chat more about these things as my former company invented WebReports and my current company is entirely focused on extending them in the modern era.

Greg

gpetti@ravenblackts.com