Article
· Apr 17, 2017 4m read
Debugging Web

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.

16 2
5 3.3K

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.

12 1
1 2.4K

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.

19 11
5 6.6K

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.

16 23
3 4.7K

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.

3 16
5 2.1K

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
3 2
2 1.6K

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.

3 2
1 1.1K

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.

2 4
0 1.5K

This series of articles aims to address the following topics:

  • Creation of a web application based on REST pages;
  • Overview of some tools for tracing (debugging) HTTP requests;
  • Switching from hyperevents to... hyperevents;
  • Integration with jQuery File Upload;
  • Conversion of JSON from the {id:1,parentId:1} format to the {id:1,children:[{}]} format for tree visualization;
  • Integration with jQuery EasyUI (using datagrid and tree as examples);
  • Other topics.

5 1
1 935

Sometimes you can face the situation when you did update the web app on Caché server but you cannot get the newest version of the app in a browser.

Here are couple recipes which help me to solve it. From simplest to more sophisticated and not obvious.

1. Refresh page in a browser

In Chrome it is Ctrl+R or 'Refresh' button. Obvious, but helpful.

2. Hard reset in a browser

If you are in Chrome, open Developer tools

2 1
0 1.4K
Article
· Apr 18, 2017 1m read
Having your Node.js Cake and Eating It Too

I've mentioned the QEWD project in this group before: it's a Node.js-based platform for web, Native and REST applications which tightly integrates with Cache. It uses a somewhat different philosophy to the use of Node.js than the norm, and I've now published an article that explains this approach and the unique benefits that arise as a result.

It turns out that, integrated via QEWD, Cache is an ideal bed-fellow for Node.js. QEWD makes the integration of Cache and Node.js exceptionally fast, simple and intuitive to use, but also extremely powerful.

Read the article here:

4 4
0 517

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

0 0
0 861
Article
· Jul 31, 2017 5m read
Introduction to QEWD Micro-Services

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:

https://smartbear.com/learn/api-design/what-are-microservices/

3 3
0 667

or "Things are going to break"

We left our application over the weekend, secure in the knowledge that it was returning data from our primary persistent class, User.Widget. However, Widgets Direct are the premier supplier of both Widgets AND Widget Accessories, so we should really start working on adding these Accessories to our application.

2 3
0 1.3K

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.

2 0
0 730

We finished our last lesson with our Widgets Direct page iterating over a list of widgets, displaying an ID and a Name value. While we have been able to achieve this with only a small amount of coding, the page itself is not the most visually appealing place to be. The AngularJS framework is providing a powerful Model-View-Controller framework for our structure and logic, but it does not implement anything that will provide a nice UI experience.

6 3
0 1.6K

At the end of our last lesson, we ended with our page displaying a nice (but garish) Angular Material Toolbar, and our Widget data displaying in a list of Material cards. Our page feels a bit static, and we already know that the large number of Widgets that we will be dealing with will not be especially usable on a static list. What can we do to help?

3 0
0 1.2K