#Angular

Hi all,

This might be a stupid question, but I'm going to ask it anyway.

My goal is to write a scss file, pack it as part of a local library (Something like my_library.tgz), npm install that library into a different project and then import that scss file in one of the scss files in the new project.

Simply having the scss file exist in the library before I pack it didn't seem to work; the file wasn't under node modules after the npm install. Am I doing something wrong, or are there extra steps I have to take?

Thanks in advance.

This article is translation of one from Habrahabr InterSystems blog (Russian).
The original post can be found here: https://habrahabr.ru/company/intersystems/blog/251611/

Background

InterSystems IRIS 2019 is going to introduce new and exciting features. One of the areas with new interesting must-to-know things is the API Management.

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.

Those of you who keep an eye on developments in the mainstream of IT will be aware that a major upheaval has been occurring over the last 5 or so years, in which JavaScript has exploded in popularity and importance. Largely as a result of its server-side incarnation - Node.js - it has broken free of just being the scripting language that you use in web browser, to becoming the world's most popular language and enterprise technology of choice.

We finished our last lesson with our Widgets Direct page receiving a Welcome message as a property of a JSON object, which was unpacked and displayed on the page. However, we are on Lesson 3, and we still haven't had any talk of displaying widgets yet.

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.

While reviewing our documentation for our ^pButtons (in IRIS renamed as ^SystemPerformance) performance monitoring utility, a customer told me: "I understand all of this, but I wish it could be simpler… easier to define profiles, manage them etc.".

After this session I thought it would be a nice exercise to try and provide some easier human interface for this.

The first step in this was to wrap a class-based API to the existing pButtons routine.

I was also able to add some more "features" like showing what profiles are currently running, their time remaining to run, previously running processes and more.

The next step was to add on top of this API, a REST API class.

With this artifact (a pButtons REST API) in hand, one can go ahead and build a modern UI on top of that.

For example -

Hi all!

I'd like to share the code we used in a hands-on session in the last InterSystems Iberia Summit (Spain) about developing a simple Angular app using InterSystems IRIS as backend.

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.

or "Bonus Breakage"

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.

Hi Developers!

Suppose you have a persistent class with data and you want to have a simple Angular UI for it to view the data and make CRUD operations.

Recently @Alberto Fuentes described how to build Angular UI for your InterSystems IRIS application using RESTForms2.

In this article, I want to tell you how you can get a simple Angular UI to CRUD and view your InterSystems IRIS class data automatically in less than 5 minutes.

Let's go!

Hi! Today I would like to talk about one of the most important architectural patterns in Angular.

The pattern itself is not related to Angular directly, but as Angular is component-driven framework, this pattern is one of the most essential for building modern Angular applications.

Container-Presentation pattern

It is believed that good components should be small, focused, independent, testable and most important - reusable.

a.k.a.. "The World of Widgets Returns!" or "Paternity leave damages Instructional Series momentum"

In our last lesson, we combined 2 separate classes to appear as the same property. We now have the ability to Update our Widget catalog, but what if we want to Create a Widget? Thankfully, we've already done 90% of what we need, just by implementing Edits