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 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.
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 ).
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 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.
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.
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.
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:
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.
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.
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:
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.:
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.
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:
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]
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:
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:
Those of you who are following the FullStack competition here in the Developer Community will know that I submitted an entry named qewd-conduit. I wanted to summarise why I think it's something worth you taking a bit of time to check out.
qewd-conduit uses the Node.js-based QEWD framework alongside IRIS to implement the back-end REST APIs for something known as the RealWorld Conduit application:
By update
Open Exchange app