Best Of

Just to add some further color to these great responses:

When you create WebReports, you are actually creating OScript. When a WebReport is submitted, the code on the backend converts the WebReports template (reportview ) into an optimized OScript file that is cached, and compiled, so when you run a WebReport you are running native, compiled Oscript code. Of course the more complex each reportview is, and the more "Tags" you use, the more Oscript code you are running, but behind the scenes you have chunks of OScript that are completely supported by OT to remain compatible with each Content Server release. That is why historically, WebReports were seen as a good alternative to native Oscript. Of course there are still ways to write bad (non-robust) WebReports if you don't actually use the tools provided. The tag library is essentially an API to use Oscript functions in a supported way.

The basic WebReports paradigm is completely analogous to many modern day "template" based technologies that allow content and tags (usually handlebar/moustache type syntax in newer languages). There are essentially three main components in every one of these technologies and the table below shows how they compare. The WebReports tag syntax is unusual, but you only need to learn these three tag types. After that it's all about the specific API endpoints provided by these tags and there is an excellent tag guide provided to learn these items. I should also note that WebReports also support OScript blocks of code that allow basic Oscript script to be added to any WebReport. Several limitations are implemented with this feature to maintain the strict API, but it does provide a simple scripting ability to supplement the template approach, as is the case with other technologies listed below. Why the funny tag syntax? Well WebReports tags were designed to match the WebForm tags that existed back in 2002-3 when WebReports was first created. This technology pre-dated more modern types or syntax with Django possibly leading the way in about 2005.

Finally, with all of the approaches listed, the success is often about design and architecture, how the application is broken down into functional components, how you query data (SQL queries are the most common reason for performance issues ), filtering and sorting can be down at the DB level, or the server level, or in the client. WebReports has historically provided a platform that allows fairly swift implementation of applications, but as with all technologies, maximum performance, security, portability, and usability require a more rigorous development process, or (as is often the way) an interactive improvement process. We see many existing WebReport customers in this phase of review and improvement and thus that is where we have focused our products and services today.

Greg Petti

The AddressBook example mentioned by @appuq is available in older versions of the CS IDE docs, but as mentioned the OT training course is a good place for the basics, but there is still a big gap between that and actual live solutions, forums like this can help along with experienced resources.

SmartUI/JATO is one interface option, but may not deliver what you need for your solution(s), e.g. Classic UI support etc. It also have a vastly different skill profile for development resources.

AnswerModules is a more developer focussed overlay that WebReports allowing deeper integration with OTCS, but again a good grounding in OScript development will help you understand why the scripts in Groovy need to be as they are etc.

Hi, it looks like my previous comment didn't make it in. Just to build on what Appu and Greg have mentioned, both extremely experienced in this area, Content Server has very many options for personalizing and customizing. In the Classis UI, there are appearances, ActiveView, WebReports and others that provide a layer of development without oScript and using common web standards like HTML, JS, CSS, etc. In the Smart View, there are widgets that allow for custom and dynamic content and custom perspectives, as well as CSS file configuration for changing the overall style. I always suggest customers look at all the options and compare to their needs and their skills in house.

One thing I will add about WebReports is that it used to be a separate purchased module, but it has since been rolled into core Content Server and is available at no extra cost, and there is a lot of solid documentation to get started, so its worth looking at as there is no cost associated with trying it. We are still using it to build full applications for Content Server, including a modern development environment with AI tools, such as in the attached screenshots.

Why not consider training? The documentation available, along with the creation of a sample module, kind of covers the most commonly used aspects of code. Also, Oscript is not a widely used software; it gets used only in OTCS, so unless a company/organization has committed towards creating a technical debt vis-à-vis you will find this difficulty. Currently, Oscript is widely used by partners who create products and modules, and it so happens that a lot of them are experienced or ex-opentexters.

Most OT installs will not even allow custom modules to be installed, especially in cloud and others, unless you are a name-brand recognized vendor/partner, so most customers get by doing lighter integrations (SOAP/REST/WR/AM).

AM (answermodules) is probably the easiest way to add functionality to OTCS in a relatively cost-effective way, as you can find a lot more Java/Groovy programmers.WR is also used as an alternate way.

For self-study, I had found that doing the addressbook module, this module is akin to a "Hello World" of Oscript .OT used to maintain it for some time. I think I was the last one who made something that works in CSIDE. This teaches the developer subtypes, request handlers,webnodes, and commands; however is geared towards Classic UI, which is weblingo.WF and Event Scripting were easy wins, but nowadays WR offers you that much more easily.

For SmartUI, you have to invest in an SDK and work through the example, although SmartUI is a way of doing powerful rest based javascript, and that is how the world is going. Perhaps with AI, SmartUI might now be easier.

https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/80231233/15106295/16376487/67794710/67790529/-/Customview.html?nodeid=80215580&vernum=-2

Hope some of it made sense :)