Front-end web development is the practice of converting data to a graphical interface, through the use of HTML, CSS, and JavaScript, so that users can view and interact with that data.
In this article I'll cover testing and debugging Caché web applications (mainly REST) with external tools. Second part covers Caché tools.
You wrote server-side code and want to test it from a client or already have a web application and it doesn't work. Here comes debugging. In this article I'll go from the easiest to use tools (browser) to the most comprehensive (packet analyzer), but first let's talk a little about most common errors and how they can be resolved.
or "So you just got yelled at by your boss, for sending him an unformatted Hello World webpage"
Our previous lesson ended with us serving a Message value obtained from a Caché REST service to the client, using Angular as a runtime. While there is a lot of moving parts involved in this process, the page is not especially exciting at the moment. Before we can start adding new features, we should take a step back and review our tools.
So, one day you're working away at WidgetsDirect, the leading supplier of widget and widget accessories, when your boss asks you to develop the new customer facing portal to allow the client base to access the next generation of Widgets..... and he wants you to use Angular 1.x to read into the department's Caché server.
There's only one problem: You've never used Angular, and don't know how to make it talk to Caché.
This guide is going to walk through the process of setting up a full Angular stack which communicates with a Caché backend using JSON over REST.
I am pleased to announce that the web terminal project, Caché WebTerminal version 4 gets its release! After long period of enhancing this web application from 2013, it came to the version 4, which features major stability and security improvements, intelligent autocomplete and syntax highlighting, convenient SQL mode and a lot of other useful features.
The goal of this article is to spread the knowledge about this project over the InterSystems community.
So, one day you're working away at WidgetsDirect, the leading supplier of widget and widget accessories, when your boss asks you to develop the new customer facing portal to allow the client base to access the next generation of Widgets..... and he wants you to use Angular 1.x to read into the department's Caché server.
There's only one problem: You've never used Angular, and don't know how to make it talk to Caché.
This guide is going to walk through the process of setting up a full Angular stack which communicates with a Caché backend using JSON over REST.
I am working on a project that will interact with some software called ROS (Robot Operating System). One of the development challenges we have is as follows:
ROS uses web sockets... So one connect with ws://localhost:9090 to the web socket server. It starts off as http, but then "upgrades" to web socket. It then keeps open this "tunnel" for bi-directional communication..
I need something like a HTTP Outbound adapter, but the Web Socket version of it...
There are several options how to deliver user interface(UI) for DeepSee BI solutions. The most common approaches are:
use native DeepSee Dashboards, get web UI in Zen and deliver it in your web apps.
use DeepSee REST API, get and build your own UI widgets and dashboards.
The 1st approach is good because of the possibility to build BI dashboards without coding relatively fast, but you are limited with preset widgets library which is expandable but with a lot of development efforts.
The 2nd provides you the way to use any comprehensive js framework (D3, Highcharts, etc) to visualize your DeepSee data, but you need to code widgets and dashboards on your own.
Today I want to tell you about yet another approach which combines both listed above and provides Angular based web UI for DeepSee Dashboards - DeepSee Web library.
In the first article I started discussing RESTForms - REST API for your persistent classes. We talked about basic features, now, I'd like to discuss advanced features - mainly queries capabilites:
Basic queries
Query arguments
Custom queries
Queries
Queries allow getting slices of data, based on arbitrary criteria. There are two query types in RESTForms:
Basic queries work for all RESTForms classes once defined and they differ only by the field list
Custom queries work only for the classes in which they are specified and available, but the developer has full access to query text
The Widgets Direct sample application highlights many aspects of how to use InterSystems technologies to build a modern web application. Features include:
In our last lesson, we added a relationship between 2 persistent classes. We are clearly going to need to start creating REST Services to expose CRUD operations for each of these classes, but before we do that, we should really finish defining our linkages. We added code to our Widget toJSON to spool off related Accessory data, so we should really do the reciprocal and allow Accessories to return all Widgets that are compatible.
or "Didn't you say you would cover Persistent Objects in Part 5, Chris?"
Yes, that was the plan. This is a pretty important topic, so it get's its own Article
Up until now, we've display widget JSON that has been created by a basic loop. Clearly this isn't of much value. Now we have our stack connected together, and we can see that the data is flowing to the Welcome page, it's time to complete the stack and start feeding our service from "real" data.
Set httprequest=##class(%Net.HttpRequest).%New()
Set httprequest.Server="www.intersystems.com"
Do httprequest.Get("/")
Do httprequest.HttpResponse.OutputToDevice()
Do httprequest.Get("/cache/")
Do httprequest.HttpResponse.OutputToDevice()
In our last lesson, we implemented a new REST Service to allow us to perform CRU operations on Widgets, and refactored our Controllers to allow the page setup to be decouple from the content.
I recently encountered a issue with Caché and I can't figure out where the problem is coming from.
I noticed that the license limit (200) was reached whenever I was opening my Studio (so it seems). When this occurs, I restart Caché (with the Cube in the Taskbar), and the number of license used is back to 1%, but grows back after. The time taken before the number of license grows back again looks pretty random.
We have an web application accessed using https, that uses CSP technology with frames.
The initial 'login' is via a single CSP page, which then redirects to another CSP page which creates the frames (4 in all) and loads a CSP page in each of those. For the most part the frames load without error, but sometimes when logging in and sometimes while using the system ' 5916 Illegal CSP Request ' errors occur.
I say 'login' in inverted commas as a Cache login is not performed just an application login, I don't know if that's relevant so thought I'd mention it.
https://www.youtube.com/embed/GRWS2fMA3Rw [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
By update
