JavaScript, often abbreviated as JS, is a high-level, interpreted programming language. It is a language which is also characterized as dynamic, weakly typed, prototype-based and multi-paradigm.
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 had posted a similar question outside this group a while ago "Errors requesting data from local Ensemble FHIR Repository" but haven't had the chance to follow up on it since. It was suggested I re-post inside this group.
I'm trying to request data from my local FHIR repository using a simple JavaScript client and am getting the following CORS errors . ( It is a standalone client not inside HealthShare without CSP etc. on my localhost ).
I wrote a step by step tutorial in the qewd-howtos repository how you can write state of the art multi-page web apps with Node.js using a QEWD-Up WebSocket/REST api back-end integrated with a mainstream web framework like NuxtJS & Vue.js.
In this article, we will cover the basics of topics listed below:
1. Routing in Flask Framework 2. Folder structure for a Flask app (Static and Template) 3. Getting and displaying data in the Flask application from IRIS.
Now available on Open Exchange is a library of third party charts available to use within DeepSee/InterSystems IRIS BI dashboards. To start, simply download and install, select the new portlet as the widget type, then select the chart type that you desire. If you don't find the type of chart you are looking for, you can easily extend the portlet to implement your desired chart type. These new chart types can be used within existing dashboards or you can create new dashboards using them.
As a result of Evgeny's recent questions regarding the use of QEWD.js with IRIS in another post, I thought it would be a good idea to create a separate post focusing specifically on how to use QEWD.js to create REST APIs for IRIS.
QEWD.js is, of course, a Node.js framework, and all the REST API code can be written entirely in JavaScript.
There's a new and exciting enhancement to QEWD that has just been released - it's an additional layer of abstraction known as QEWD-Up. QEWD-Up hides away all the mechanics of QEWD itself, allowing you to focus on just your REST APIs and the code that implements them.
Additionally, and importantly, QEWD-Up simplifies the maintenance of your REST APIs, allowing you (and others) to quickly and easily understand their life-cycle and implementation.
In our last lesson, we added a form to Edit our existing Widgets, and save them back to the server. However, our Form was not well structured and our Save button had no intelligence, and was not fully visible. So today, we will apply some Material components and Angular style to make the form more useful
In our last lesson, we added some formatting and validation to our Edit Widget form. So, now we are ready to add the ability to add new Widgets to our application. However, the great Widget Wars have come to an abrupt end, as Widget Direct has purchased its biggest competitor, WorldWideWidgets. In order to maintain some continuity, we need to display their catalog on our new application.
In my previous posting about the new support in QEWD for JSON Web Token (JWT) support, I mentioned that it was a key step in enabling Micro-Service support in QEWD. In this post I'll give some background to how they work and the thinking behind them.
If you haven't heard about Micro-Services and/or want to learn more, there's lots of information available if you do a Google Search. Here's a good starting point:
Recently I reread this article by @Bernd Mueller. It's about calling DELFATE function from zlib library. In this article I'll demonstrate several different approaches to callout libraries, we'll build the same functionality (compress function) in several different languages and compare them.
NLP stands for Natural Language Processing which is a field of Artificial Intelligence with a lot of complexity and
techniques to in short words "understand what are you talking about".
And FHIR is...???
FHIR stands for Fast Healthcare Interoperability Resources and is a standard to data structures for healthcare. There are
some good articles here explainig better how FHIR interact with Intersystems IRIS.
IRIS provides us with anti login CSRF attack mitigation, however this is not the same as a CSRF attack, as login attacks only occur on the login form. There are currently no built-in tools to mitigate CSRF attacks on api calls and other forms, so this is a step in mitigating these attacks.
See the following link from OWASP for the definition of a CSRF attack:
This is a quick note on what happens when, on your CSP page, you call a cache script which returns a %Boolean and store that value in a javascript variable.
When you call a script with language="cache" and returntype="%Boolean" from a javascript script, the return value is interpreted as a string, not as a boolean.
Here's an example:
A cache script that returns (in theory) a "false" value:
Users of analytical applications often need to generate and send out PDF reports comprised of elements of the analytical panel. In the InterSystems stack, this task is solved using the DSW Reports project that is an extension of DeepSeeWeb. In this article, we will explain how to use DSW Reports for generating PDF reports and emailing them.
Quite a few enhancements have appeared over recent months in QEWD for easing and simplifying the creation of REST-based services. It's now even more slick and powerful, allowing you to very quickly create very high-performance, highly-scalable REST (and Web) services that make use of Cache.
I've therefore updated the training presentation deck (Part 31 on developing REST Services with QEWD). It describes all the new features with worked examples. See:
https://www.youtube.com/embed/sLq2NRf0xq4 [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]
We have a application currently running on Zen framework, now business wants to use Angular JS as their front-end technology for any future release but they don't want to upgrade the existing the modules which are already there in Zen (as of now).
This concept may be known to some, but I just found it very useful and I would like to share as it may help someone else.
If you are working with CSP or Zen you sometimes come across the need to use embedded JavaScript. Suppose you are working with some loops, which use < or > as shown in example below:
If I test the Native api for Node.js from the documentation, I noticed (if I'm correct) all methods and calls are synchronous. By default due to the nature of Node.js, there is only one thread of execution and normally all JavaScript methods and all calls should be asynchronous and use either a callback function (the "old way") or promises or the async/await contruct to return their result, e.g.:
Most frameworks support either REST or WebSockets, and don't make it easy to switch between the two, and/or support both styles of application at the same time. WebSockets offer many advantages over REST, eg:
- most benchmarks show WebSocket messaging to be significantly faster than over HTTP
By views
Open Exchange app
