Check out our Angular Book Series.

How do I create a REST service in PHP?

I've been working to update the LearnWith series. The series builds UI applications--right now with Angular--and multiple backends with NodeJS, or ColdFusion. I'm creating a new book that creates services in PHP.

How do you create a REST service in PHP?

I did it this way. First, add a header:


header("Content-Type: application/json; charset=UTF-8");

The Content-Type header says the results will be in JSON.

Then, get the request type:


$method = $_SERVER['REQUEST_METHOD'];

The $method variable will be GET, or POST, or PUT, or whatever REST protocol you're using.

Then, use a switch statement to determine the type of request:

switch ($method) {
case 'GET':
// access URL Variables
// $_GET["myvar"])
// data retrieval here;
echo(json_encode($result));
break;
case 'PUT':
// retrieve PUT body data
$data = json_decode(file_get_contents('php://input'));
// $data->
myvar
// Update data Here
echo(json_encode($result) );
break;
case 'POST':
// retrieve POST Body data
$data = json_decode(file_get_contents('php://input'));
// $data->myvar
// Create some data Here
echo(json_encode($result) );
break;
default:
echo("Unknown Request Type");
break;
}

That is pretty much it. For get requests, you can access URL variables directly, like this:


$_GET["myvar"])

For PUT or POST requests, you'll most likely be sending a JSON object as the body of the request and you can access it like this:


$data = json_decode(file_get_contents('php://input'));

I hope this helps someone. Be sure to check out my LearnWith series, where you'll be able to find information about integrating Angular and AngularJS with PHP very soon.

How do I Fix Uncaught (in promise): Error: StaticInjectorError[] in Angular 5?

I've updated my Learn With Programming Books to Angular 5. Angular changed their versioning structure, so Angular 5 is more like Angular 2.2 than a complete update.

Unfortunately, the upgrade was not seamless and this error drove me insane. Everything I thought I'd fix it, it would crop back up:


ERROR Error: Uncaught (in promise): Error: StaticInjectorError[UserModel]:
StaticInjectorError[UserModel]:
NullInjectorError: No provider for UserModel!
Error: NullInjectorError: No provider for UserModel!
at _NullInjector.get (injector.js:31) [angular]
etc.. etc..

The error looked like this:

The underlying cause of this error is that Angular 5 changed how they create providers moving from a reflect based injector to a static injector. This removes the need for the reflect polyfill that is used in Angular applications. Without digging deep into Angular code I can't explain better, all I knew was that I had the error and needed a resolution.

If you search, you'll find a lot of write ups on this, but it was trial and error that solved the issue for me. Here are two things to look at that helped me solve the issue.

Check Your TypeScript Version

Angular 5 requires TypeScript 2.3 or later, so make sure that your build scripts have the proper version installed. I'm using TypeScript 2.4, and your package.json should look something like this:


"typescript": "^2.4.0",

If you're using the Angular CLI this shouldn't be an issue, as it should already have the proper versions set up.

Check Case Sensitivity of Classes and Imports

This is the one that drove me nuts. About half of my development standards come from 'legacy' applications, and the rule of thumb used to be to name class files in proper case, so UserModel.ts instead of usermodel.ts. However, it appears--and I'm not sure why--that Angular has a problem with the mixed case of the class imports. If I was importing two classes from the same directory and setting them up as providers in the main application, I would get this error.

This would cause errors:


import {UserModel} from "../model/UserModel";
import {TaskModel} from "../model/TaskModel";


@NgModule({
// other stuff here
providers : [ UserModel, TaskModel]
})

This would not:


import {UserModel} from "../model/usermodel";
import {TaskModel} from "../model/taskmodel";


@NgModule({
// other stuff here
providers : [ UserModel, TaskModel]
})

Even if I changed nothing with the actual import files. By putting all the class imports in lower case, I was able to avoid the issue.

That was until I set up unit tests using karma-typescript. Karma TypeScript spit up on the imports with incorrect case. I ended up putting the file names in all lower case so they would be fine with my Angular Build Scripts and with the Karma TypeScript tests.

Final Thoughts

I thought the upgrade, and book update, would be a couple of days, but took me a full week. So, go check out my Angular 5 books, or at least get on my mailing list using the form below.

Keep up to date by reading DotComIt's Monthly Technical Newsletter

Enable Double Opt In for MailChimp APIs

I was using some very old code to power the "Join my mailing list" boxes on my various sites. It stopped working perfectly a while back and I've been rewriting the code to use the MailChimp 3.0 APIs instead of the MailChimp 1.3 API.

Setting it up was a lot easier than I expected. The first thing I noticed after rolling it out, however, was that users were being subscribed immediately to the mailing list without using the double opt in. Obviously this is a nightmare, despite the new MailChimp defaults. You do not ever want use single opt in.

I was using this API to add new members to a list. I pulled directly from a sample in their docs:


{
"email_address": "urist.mcvankab@freddiesjokes.com",
"status": "subscribed",
"merge_fields": {
"FNAME": "Urist",
"LNAME": "McVankab"
}
}

The reason double opt in was being bypassed was because of the status of the user. I put the status as subscribed, which is a way to tell mailchimp they already double opted in. To fix my problem, I needed to change to that pending, something like this:


{
"email_address": "urist.mcvankab@freddiesjokes.com",
"status": "pending",
"merge_fields": {
"FNAME": "Urist",
"LNAME": "McVankab"
}
}

The API assumes that subscribed means they are in, but pending means they still need to approve the sign up. More details on the user statuses are on the same page with information about managing subscribers, but sadly not mentioned on the API Doc page.

I'm surprised how easy it was to set up the API Integration, so Kudos to MailChimp for that. I wish the API Docs were more detailed on the meaning and values of certain fields.

Testing a Bootstrap Popup with Angular - Part 2

This is the second half of my article on testing a Bootstrap popup. Before reading this, you should read my post about creating a popup with Angular and Bootstrap, and the one about testing the popup component. This post will focus on testing the code that creates the popup.

Review Code

In my test sample, the code to create the popup is in the app.component.ts file. This is it:


onModalRequest():void {
const modalRef = this.modalService.open(PopupComponent );

modalRef.result.then((result) =>
{
console.log(result);
console.log('closed');
}).catch( (result) => {
console.log(result);
console.log('cancelling');
});
}

This is triggered by button click in the view. Create an instance of the modal using the modalService, which is an instance of the NgbModal. It saves that instance in another variable, modalRef. The modalRef.result is a promise, and we can use that to run code whenever the modal is closed or dismissed. The promise then() method represents a successful closure of the modal. The promise catch() method represents a dismissal. Since this is a test app, the close and dismiss methods don't do anything other than log items out to the console, but a real app may save data or update a view.

We're going to write a few tests against this code. The first will just verify that the modal opened. Then we'll open and close the modal, verifying that the result function was called. Then we'll open and dismiss the modal, verifying that the catch function was called.

Write the Tests

I put my tests in a file named app.component.test.ts. As always, we'll start with the imports. These are the Angular testing imports and the ng-bootstrap imports:


import {async, TestBed,ComponentFixture} from '@angular/core/testing';
import {NgbModal, NgbModalRef } from "@ng-bootstrap/ng-bootstrap";

Now, load our custom components:


import {AppComponent} from "../../../../../src/com/dotComIt/learnWith/main/app.component";
import {PopupComponent} from "../../../../../src/com/dotComIt/learnWith/views/popup/popup.component";

We import the AppComponent, which contains the code we'll be testing and the PopupComponent which contains the code we'll be testing. Now, create a describe function to create the set of unit tests:


describe('AppComponent', function () {
});

Next, create a bunch of variables inside the describe:


let fixture: ComponentFixture<AppComponent>;
let appComponent: AppComponent;
let modalService: NgbModal;
let modalRef: NgbModalRef;

The ComponentFixture is used to create an instance of a component so you can access all properties, methods, and DOM elements of its HTML template. The appComponent is an instance of the component's class. The modalService and modalRef relate to the popup window that will be created.

Here is a beforeEach():


beforeEach(async(() =>
{
TestBed.compileComponents().then(() => {
modalService = TestBed.get(NgbModal);
modalRef = modalService.open(PopupComponent);
fixture = TestBed.createComponent(AppComponent);
appComponent = fixture.componentInstance;
spyOn(modalService, "open").and.returnValue(modalRef);
spyOn(console,'log').and.callThrough();
});
}));

It compiles the components on the TestBed. Remember the TestBed was configured in a base.test.ts file, which our scripts know to compile first. After the components are compiled, we get the modalService and create a modalRef by opening the component. The fixture instance of the AppComponent is stored as is its componentInstance.

Finally the beforeEach() creates two spyOn() methods. It looks at the open method of the modalService, and tells it to return the modalRef as a specific value. Then it spys on the console.log() method. Normally I would try to avoid spying on this, but since no real functionality exists inside our app this is the best way to determine if the close or dismiss methods will run on the modal popup.

Let's start off with an easy test, to see that the modal opened:


it('Modal Opened', function () {
appComponent.onModalRequest();
expect(modalService.open).toHaveBeenCalled();
});

This is pretty self-explanatory. It calls the appComponent's onModalRequest() creates the modal, and checks to see that the open method had been called, insinuating that the modal had been created.

Let's create the modal, then close it:


it('Modal Opened, then Closed', (done : DoneFn) =>
{
appComponent.onModalRequest();
fixture.detectChanges();
fixture.whenStable().then(() => {
modalRef.close();
fixture.whenStable().then(() => {
expect(console.log).toHaveBeenCalledWith('closed')
done();
});
});
});

First thing you notice is that a done() function is passed into the test function. This is a function that tells Jasmine to run the code asynchronously. This is a special Jasmine construct, and is different than the async or fakeAsync test beds which are Angular constructs. The Angular constructs have all sorts of issues if you use any sort of timer under the hood, and gave me lots of problems when I was writing the test code for the learn with app. This approach avoids those issues.

Next, the onModalRequest() method is called on the appComponent. Then we access the fixture to detectChanges(). This tells the component to process a digest cycle. It will redraw whatever needs redrawing. In our case, it waits for the modal to actually be created and opened. Then we wait until the fixture is stable using the whenStable() function. This means the modal was created and it is all good to continue. The whenStable() method returns a promise, and we execute the success function on it. Inside the success function we call a close() method on the modalRef value. We do not need to call the detectChanges() again, but we do need to wait until code is stable before running our assertion. The assertion excepts that console.log() will have been called with the value "closed". This is the hard coded result value inside the main app component code. Finally it calls the done() function to tell Jasmine that we are done running async code. This completes the test

To test the dismiss function, we use a similar approach, but I needed an extra level of waiting until the component fixture was stable before I could check for the dismiss function to have been called:


it('Modal Opened, then dismissed', (done : DoneFn) =>
{
appComponent.onModalRequest();
fixture.detectChanges();
fixture.whenStable().then(() => {
modalRef.dismiss();
fixture.whenStable().then(() => {
fixture.whenStable().then(() => {
expect(console.log).toHaveBeenCalledWith('cancelling')
done();
});
});
});
});

The code opens the modal with appcomponent.onModalRequest(). Then it calls fixture.detectChanges() to watch for the DOM changes. Then it uses whenStable() to make sure the modal opened. When it is open, it is dismissed. Then it waits until it's stable twice before running the assertion. The assertion checks that the console.log() method was called with the 'cancelling' string. Then it calls the done() function, finishing off this method.

Run it:


Gulp test

And you'll see results like this:

Final Thoughts

When researching how to test a popup with Bootstrap and Angular 4 I found a lot of conflicting information. But, I hobbled through it and found this approach which seemed to work well for me. I wrote a full 70 pages on Unit Testing in the bonus book to my Angular 4 series. Get it now!

Keep up to date by reading DotComIt's Monthly Technical Newsletter

Testing a Bootstrap Popup with Angular - Part 1

Last week's post showed you how to create a popup using Angular 4 and ng-bootstrap. This week, I'll show you how to test it. This post covers testing the popup component. Next week I'll test creating the popup.

Get a Testing Framework

You'll need a testing framework. I have my own scripts based on Karma, Jasmine, and karma-typescript. I write about this in full details in the companion book to my Angular 4 book series. You could also use the Angular CLI or scripts of your own choosing. Specifics of the setup is beyond the scope of this article, because I want to focus on the tesing technique.

Configure the Test Module

Angular includes a testing construct called TestBed. This is a module created for testing other modules and is considered the foundation of all Angular tests. We're going to create a base.test.ts file to set up the TestBed to parallel the main application. This will parallel the main application from our source app.

It doesn't matter where you create the base.test.ts file as long as it is loaded by your testing code, and your apps main module is ignored. I place it in the root of a testing directory. When the app runs in a browser, the index loads a shim library and a ZoneJS library that are required by Angular. But the tests are not run in a browser, so we need to import these scripts manually, like this:


import "core-js"
import "zone.js/dist/zone";
import "zone.js/dist/long-stack-trace-zone";
import "zone.js/dist/proxy";
import "zone.js/dist/sync-test";
import "zone.js/dist/jasmine-patch";
import "zone.js/dist/async-test";
import "zone.js/dist/fake-async-test";

This will prevent a lot of confused errors about uncaught reflect-metadata and class decorators. Now we need to import the Angular specific testing modules:


import { TestBed } from "@angular/core/testing";
import { BrowserDynamicTestingModule, platformBrowserDynamicTesting } from "@angular/platform-browser-dynamic/testing";

This imports the TestBed which is the testing module. It also imports BrowserDynamicTestingModule and platformBrowserDynamicTesting. These are used to parallel the platformBrowserDynamic class which loads the initial application.

With these imported we can immediately initialize the TestBed:


TestBed.initTestEnvironment(BrowserDynamicTestingModule, platformBrowserDynamicTesting());

Now import the BrowserModule which is the ng module for the browser, and the NgbModule, which contains the ng-bootstrap libraries:


import { BrowserModule } from '@angular/platform-browser';
import {NgbModule} from '@ng-bootstrap/ng-bootstrap';

Now, import the custom components from our demo:


import { AppComponent } from '../src/com/dotComIt/learnWith/main/app.component';
import { PopupComponent } from '../src/com/dotComIt/learnWith/views/popup/popup.component';

Now, configure the TestBed:


beforeEach(() =>
{
TestBed.configureTestingModule({
imports : [BrowserModule, NgbModule.forRoot()],
declarations: [ AppComponent, PopupComponent ]
}).overrideModule(BrowserDynamicTestingModule, {
set: {
entryComponents: [ PopupComponent ]
}
})
});

The first thing to notice is that I put the TestBed configuration in a beforeEach() function. What is beforeEach()? It is a special function that is part of the Jasmine testing framework. The function allows you to run code before the tests are executed. We use it to create and configure the testing module which will be used by most of our other unit tests. You can have multiple beforeEach() functions if needed, but here we only need one.

The configureTestingModule() accepts a configuration object which sets up imports for other modules and declarations for components. This is all like the @NgModule metadata in our main application. The configureTestingModule() does not support entryComponents, unfortunately. We used the entryComponents metadata to set up the component that ng-bootstrap will use to create the modal.

Thankfully there is a workaround. We daisy chain an overrideModule() method after the configureTestingModule is created to add the entryComponents metadata.

That's all we need in the base.test.ts file. Notice there is no formal export of a class. It isn't needed, since no other classes will use this explicitly. Be sure this file is compiled into your tests before your other code to avoid compile errors.

Test the Popup

Now, we're going to test the PopupComponent. There are two methods that we care to test:


onDismiss(reason : String):void {
this.activeModal.dismiss(reason);
}
onClose():void {
this.activeModal.close('closed');
}

The first is the onDismiss() method, which will occur if the user cancels the popup. It means all changes are cancelled. The second method is the onClose() method and it occurs if the user formally closes the popup with the close button.

Create a file named popup.componment.test.ts. Start with imports:


import {async, TestBed} from '@angular/core/testing';
import {NgbModal, NgbModalRef, NgbActiveModal} from "@ng-bootstrap/ng-bootstrap";
import {PopupComponent} from "../../../../../../src/com/dotComIt/learnWith/views/popup/popup.component";

It imports the async and TestBed modules. The async import is used to run a beforeEach() or it() test inside an async test zone that mocks the mechanics of asynchronous processing. Then some modal specific classes are imported from ng-bootstrap. Finally our custom PopupComponent is loaded.

Now, create a describe function:


describe('popupcomponent', function () {
});

The describe() function is a Jasmine function that defines a test suite, which is a collection of related tests. The function takes two arguments. The first argument is a string that is the name of the test suite, in this case 'Sample Tests'. The second argument is a function, which runs the tests. You can embed a describe() function inside other describe() functions if you feel it is relevant to your testing.

Create two variables inside the describe() block:


let comp: PopupComponent;
let activeModal : NgbActiveModal;

We'll define these values in a beforeEach() block and reuse them in individual tests. Look at the beforeEach() next:


beforeEach(async(() =>
{
TestBed.compileComponents().then(() => {
let modalService : NgbModal = TestBed.get(NgbModal);
const modalRef : NgbModalRef = modalService.open(PopupComponent);
comp = modalRef.componentInstance;
activeModal = comp.activeModal;
});
}));

We compile the components on the TestBed. This returns a promise, which we use to get access to the global variables our tests will need. First it creates a local instance of the modalService. It uses that modalService to open the popup and create the modalRef variable. The component instance is saved off the modalRef. And the activeModal value is pulled out of the component for easy access.

The first test:


it('should create component', () =>
expect(comp).toBeDefined() );

The it() function defines the test. It has two arguments, and the first is the descriptive name of the test. If it fails, you can use this name to determine which test actually failed. The second argument is a function that performs the test.

The test is written to be easily parsable:


expect(comp).toBeDefined()

This is called an assertion. We expect the component to be defined. This will return true if the component exists, or false if the component does not exist. This is often an easy test to run to make sure you have your configuration set up correctly.

Let's write a test for the onDismiss() method:


it('Call onDismiss()', () =>
{
spyOn(activeModal, 'dismiss');
comp.onDismiss('Some Reason');
expect(activeModal.dismiss).toHaveBeenCalled();
expect(activeModal.dismiss).toHaveBeenCalledWith('Some Reason');
});

This test uses a new command, spyOn(). The spyOn() method is used to watch an object for a method call. You can use this in tests to intercept the method and return specific values. Alternatively, you could use it to verify that a certain method was called. The spyOn() is looking at the activeModal as the first argument, and the dismiss method as the second argument. Then the onDismiss() method is called on the component. Two tests follow. One to make sure that the dismiss() function was called. And the second to make sure it was called with a specific argument, 'Some Reason'.

The test of the onClose() method operates using a similar fashion:


it('Call onClose()', () =>
{
spyOn(activeModal, 'close');
comp.onClose();
expect(activeModal.close).toHaveBeenCalled();
expect(activeModal.close).toHaveBeenCalledWith('closed');
});

Instead of spying on the dismiss method of the active modal we spy on the close method. And that is the method we check in the two assertions.

Try this out by running your tests. If you use my seed, use this:


Gulp test

And you'll see something like this:

Final Thoughts

This concludes this article, but I have another one coming out next week. It will examine the code I use to test the component that creates the popup.

If you want all this information and more, get my the bonus book to my Angular 4 book series. It shows you how to create an app from scratch, and covers Angular CLI, unit testing, debugging techniques, and how to build your own project seed.

Keep up to date by reading DotComIt's Monthly Technical Newsletter

Creating a Popup with Bootstrap and Angular

How does one create a modal window with Bootstrap and Angular 4? This post will show you how.

The Setup

First, we need a generic app. You can use the Angular CLI, or my own seed project to create one. They are all going to give you a similar code base, although the directory structure is a bit different. I'm going to continue using the seed project I created, so you may have to make minor tweaks to the setup for other options.

Next be sure to install ng-bootstrap using Node:


npm install --save @ng-bootstrap/ng-bootstrap

If using the Angular Quickstart or the DotComIt seed project, you'll have to tell SystemJS how to find it. Open the SystemJS config and add this to the map property:


'@ng-bootstrap/ng-bootstrap': 'js:@ng-bootstrap/ng-bootstrap/bundles/ng-bootstrap.js'

The seed project scripts will need to copy the Bootstrap libraries into the build directory. Just find the angularLibraries array in the config.js file and add the new entry:


'@ng-bootstrap/ng-bootstrap/bundles/ng-bootstrap.js'

Now open up the index.html file and add the bootstrap CSS:


<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/css/bootstrap.min.css" />

Create the Pop Component

Now, let's create a component that will be the popup. Create a file named popup.component.ts in src/com/dotComIt/learnWith/views/popup. First, add your imports:


import {Component} from '@angular/core';
import {NgbActiveModal} from "@ng-bootstrap/ng-bootstrap";

This imports the Component so we can create this class as a component. It also imports the NgbActiveModal. This will allow us to close the modal.

Create the @Component metadata:


@Component({
selector: 'Popup',
templateUrl : './com/dotComIt/learnWith/views/popup/popup.component.html',
styleUrls: [ './com/dotComIt/learnWith/views/popup/popup.component.css' ]
})

I named the selector Popup, although we won't need that. I also specified an external HTML template and an external CSS file. I do this as a matter of habit. The CSS file can be empty. We'll roll back to the HTML file in a bit. For now, create the class:


export class PopupComponent {
}

Not much there. Add in a constructor:


constructor(public activeModal: NgbActiveModal) {
}

The constructor will inject an instance of the NgbActiveModal class into this component using Angular's Dependency Injection syntax.

Finally, we'll add two methods. The first is to close the popup:


onClose():void {
this.activeModal.close('closed');
}

Closing the popup usually means the user is done interacting with it and wants to move on to other things.


onDismiss(reason : String):void {
this.activeModal.dismiss(reason);
}

Dismissing the popup means the user is cancelling the operation. Both methods will be referenced inside the HTML template. Overall there is not much to this Angular Component, because I left it simple for sample purposes. It could get as complex as you need it to.

Now look at the popup.component.html file. Start with a header:


<div class="modal-header">
<h4 class="modal-title">Test Modal</h4>
<button type="button" class="close" aria-label="Close" (click)="onDismiss('Cross click')">
<span aria-hidden="true">x</span>
</button>
</div>

The header includes a Title and an X button. When the X button is clicked, the onDismiss() method is called. Dismissing the modal is like cancelling it, whereas closing it usually means you are done with it.

Now, add a body:


<div class="modal-body">
Modal Body
</div>

Not much there, just some test text. Finally, add a footer:


<div class="modal-footer">
<button class="btn btn-primary" type="button" (click)="onDismiss('Close click')">Cancel</button>
<button class="btn btn-warning" type="button" (click)="onClose()">Close</button>
</div>

The footer includes two buttons. One is a cancel button which will dismiss the modal. The other is a close button. Both call the related methods inside the component.

That's all we need to create the component that will display inside the modal.

Modify the Main App Component

Open up the app.component.ts file. Modify the template to be like this:


template : '<button (click)="onModalRequest()">Open Modal</button>'

There is a single button which will call an onModalRequest() function. The onModalRequest() function goes in the class body of the AppComponent. But, first be sure that the constructor injects ng-bootstrap's NgbModal


constructor(private modalService: NgbModal) {
}

Now, look at the onModalRequest() method:


onModalRequest():void {
const modalRef = this.modalService.open(PopupComponent );

modalRef.result.then((result) =>
{
console.log(result);
console.log('closed');
}).catch( (result) => {
console.log(result);
console.log('cancelling');
});
}

First, the modalRef is created using the mmodalService.open() method. The PopupComponent is sent in as an argument, so be sure to import it. The modalRef.result is a promise object. If the modal is closed then the result function will be executed. If it is dismissed the failure function will execute. For both of these functions, I'm just outputting the results to the log. /

Modify the app.module

We need to tell the @NgModule about the popup component. First, review the imports:


import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import {NgbModule} from '@ng-bootstrap/ng-bootstrap';

import { AppComponent } from './app.component';
import {PopupComponent} from "../views/popup/popup.component";

The first two imports are from the angular library. The second one comes from the ng-bootstrap library. The final two imports related to our custom code.

Create the NgModule metadata:


@NgModule({
})

I started it empty. First, add the imports:


imports: [
BrowserModule,
NgbModule.forRoot()
],

It loads the BrowserM

Now the declarations:


declarations: [
AppComponent,
PopupComponent
],

The declarations tells the module which of our custom components need to be ready for use.

Next, bootstrap our app's main component:


bootstrap: [ AppComponent ],

Good to go!

And finally, add the PopupComponent the the entryComponents array:


entryComponents: [PopupComponent]

This is important because this is how we tell Angular to allow this component instance to be created on the fly with our code.

Finally, after the metadata, export the component class:


export class AppModule { }

Test It

Now you can test things. Open the app in a browser:

Now, click the Open Modal button:

Click the X or Cancel Button. You should see a message show up in the console:

Open it again, and click the close button:

You are good to go. I wrote this post as a prelude to testing Bootstrap Popups with Angular. Those articles will come over the next few weeks. In the meantime, get my new book series on Angular 4 which uses similar techniques.

Keep up to date by reading DotComIt's Monthly Technical Newsletter

Running Eclipse on the Surface Book

This question comes in from a reader who found my post about using the Surface Book as a programmer. I thought it might make a blog-worthy followup. This was Eric's question:

I am having trouble running Eclipse IDE on my Surface Book.

Eclipse works, except that the "console" that my program calls for is teeny tiny. Like an inch and a half squared on my 3000 x 2000 screen. Fonts in the console also are minuscule -- I cannot even read them easily with a magnifying glass . Tried everything (adjusting font sizes in eclipse, running compatibility tests in windows) to no avail.

Any ideas on how I can resolve this? Thanks in advance.

This is one of the biggest problems with the Surface Book. Eclipse--and a lot of other programs--are not high DPI Aware. It sucks, but it is getting better. The solution probably lies here.

That post is for Photoshop and other Adobe tools, but it works for just about everything. First, you do a registry edit to tell Windows to look for an external manifest file.

Then you create the manifest file in the install directory of your file. Name the file the executable with a .manifest' at the end. So, for Eclipse the execution program is ecliipse.exe and the manifest file will be eclipse.exe.manifest.

This is the manifest text:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">

<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*">

</assemblyIdentity>
</dependentAssembly>
</dependency>

<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.VC90.CRT"
version="9.0.21022.8"
processorArchitecture="amd64"
publicKeyToken="1fc8b3b9a1e18e3b">

</assemblyIdentity>
</dependentAssembly>
</dependency>

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>

</requestedPrivileges>
</security>
</trustInfo>

<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
</asmv3:windowsSettings>
</asmv3:application>

</assembly>

Reload eclipse and things should be better. I recently uninstalled Eclipse since I'm not on any client projects using it. I prefer IntelliJ when I can. Major windows updates will probably reset the registry setting. Just this morning, my creators update borked it.

About half of the programs on my machine use this 'manifest' trick to make the programs usable. I even created manifest files for javaw.exe and java.exe from my Java install.

And as a corollary, if you're using a lot of Remote Desktop Connections, use Terminals. It has settings to prevent the remote desktop from skewing way too small due to the same high DPI issues.

Angular Unit Testing: How do I Fix a Platform with a Different Configuration Has Been Created?

I've run into this one a few times. You're setting up Unit Testing of an Angular application and get an error like this:

Uncaught Error: A platform with a different configuration has been created. Please destroy it first.

It's frustrating and a but confusing. If you Google on that error you'll find a bunch of stuff, but no explicit solution.

You've probably set up a TestBed configuration environment as part of your unit testing, probably like this:


import { TestBed } from "@angular/core/testing";
import { BrowserDynamicTestingModule,
platformBrowserDynamicTesting } from "@angular/platform-browser-dynamic/testing";

TestBed.initTestEnvironment(BrowserDynamicTestingModule, platformBrowserDynamicTesting());

However, somewhere in the code, the non-testing modules have been loaded, probably like this:


import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app.module';

platformBrowserDynamic().bootstrapModule(AppModule);

The error occurs because of the conflict between the platformBrowserDynamic() and the platformBrowserDynamicTesting(). Make sure that you exclude the source files the import and initialization of the non-test version of the library.

In your karma.conf.js file add an exclude property to the Karma configuration object, something like this:


exclude : "src/app/main.ts",

In my case, today, the error was related to a missing '/' in the excluded directory structure.

I hope this helps someone.

How do I fix IE11 problems with CSS Calc and min-height?

I hate it when you have a problem that you cannot replicate in a simple example. That's exactly where I am. I'm working on an application built with HTML, CSS, and various JavaScript frameworks. The application requires a footer to be aligned at the bottom of the page. If the content is too large for the page, then the the footer should show up under the content. But, if the content is too small for the page, the footer should show up at the bottom of the window, or viewport.

This should be pretty simple to build using CSS and HTML:


<div class="wrapper">
Lots of Main Content and navigation and headers Here
</div>
<footer>
Some Footer Information Here that should always be at the bottom of the page
</footer>

The CSS would be something like this:


html, body {
height: 100vh;
margin : 0;
}

.wrapper {
min-height: calc(100% - 200px);
}

footer {
height : 200px;
background-color : blue;
}

The actual client project code is a lot more complex, but this gives you the gist. Play with the code here. Ignore my design skills.

The problem I was having was that IE11 seemed to have a problem with the min-height. When clicking in the page, or clicking a link to go to another page, it was as if the wrapper's min-height would shrink down on pages where the view height was greater than the actual content. This would cause the footer to jump to the middle of the page.

For the life of me, I haven't been able to create a simple sample to demonstrate this. Some part of the client's custom code seems to be causing this.

After some head banging and conferring with my team, I came up with this solution. It makes use of JavaScript and JQuery to 'hard code' the min-height on the wrapper. Instead of using the CSS Calc. this happens when the page loads and whenever the page is resized.


if(/MSIE \d|Trident.*rv:/.test(navigator.userAgent)){
function onResize(){
     /* The jquery calc code */
     $('.wrapper').css('min-height', '100%').css('min-height', '-=200px');
}

$(window).resize(function() {
onResize()
});

$(window).ready(function(){
onResize()
});

}

I used a regex trick to only execute the code for IE browsers. And I used this answer as a base for my solution.

Part of our problem solving this was my inability to create a simple reproducible case, but pouring over thousands of line of code I could not find the magic style combination that caused the 'footer jump' problem.

Frustrating; but the JS code above seems to solve the issue admirably.

Create TypeScript Modules - - Part 8

This is the last in my series of articles intended to introduce you to Typescript. It is bonus material I wrote for my Angular 4 book. This is the last part of the series. Check out part 1, part 2, Part 3, Part 4, Part 5. and Part 6, and Part 7.

When writing a real-world application, it does not make sense to include all the code in a single file. TypeScript supports that by allowing you to expand different functionality into modules.

Create Interface Module

The first thing we're going to do is create a module for the name interface. I put this in a file named IFile.ts:


export interface name {
firstName: string;
middleInitial? : string;
lastName: string;
getName() : string;
};

This looks exactly like the Interface created in the previous exception with the one addition of the export keyword. Export tells the compiler that this class is available for use inside other classes.

Create Class Modules

Now create the Person class:


export class Person implements name {
firstName: string;
middleInitial : string;
lastName: string;
getName() : string {
return this.firstName + ' ' + this.middleInitial + ' ' + this.lastName;
}
}

This also puts the export keyword in front of the class definition. If you try this you'll notice an immediate error. The name is not defined. To define it we'll need to add an import statement:


import {name} from "./IName";

The import statement tells you that the name entity is imported from the IName file and can be used within this class. The path I used, './IName', tells us that the files are in the same directory, however we can use a more elaborate package setup, and most likely you will do that for main applications.

We can create the Pets.ts module in the same manner:


import {name} from "./IName";

export class Pet implements name {
firstName: string;
lastName: string;
type : string;
getName() : string {
return this.firstName + ' ' + this.lastName + ", " + this.type;
}
}

This code mirrors the Person module, with the primary changes being the use of the export keyword before the class definition and the import of the name interface.

The Echo class needs a similar rework:


import {name} from "./IName";

export class Echo {
static readonly messageIntro : string = "Hello"
subjectArray : name[];
private message : string;
constructor(subjects : name[]){
this.subjectArray = subjects;
}
createMessage():void{
this.message = '';
for (let person of this.subjectArray){
this.message += Echo.messageIntro + " " + person.getName() + "<br/>";
}
}
echo():string{
return this.message;
}
}

The functionality remains unchanged. Like the previous classes it uses an export statement to make the class available elsewhere, and an import statement to make use of the name interface.

Rework Main Application

With all the classes stored in separate files, our primary app has become a lot simpler. First, import all the classes:


import {name} from "./IName";
import {Person} from "./Person";
import {Pet} from "./Pet";
import {Echo} from "./Echo";

Then, create the nameArray:


let nameArray : name[] = [];

Now, populate the nameArray:


let jeffryInstance : Person = new Person();
jeffryInstance.firstName = "Jeffry";
jeffryInstance.middleInitial = "A";
jeffryInstance.lastName = "Houser";
nameArray.push(jeffryInstance);

let hercInstance : Pet = new Pet();
hercInstance.firstName = "Hercules";
hercInstance.lastName = "Houser";
hercInstance.type = "Dog";
nameArray.push(hercInstance);

let zeusInstance : Pet = new Pet();
zeusInstance.firstName = "Isadora";
zeusInstance.lastName = "Houser";
zeusInstance.type = "Dragon";
nameArray.push(zeusInstance);

Create an instance of the Echo class:


let echoInstance : Echo = new Echo(nameArray);

Call the createMessage() function:


echoInstance.createMessage();

Finally, output the results:


document.body.innerHTML = echoInstance.echo();

The changes here was, primarily, removing the class and interface definitions and replacing them with imports.

Setup Module Loader

The import statement is not a native JavaScript statement and does not have an easy parallel. To make code like this work in the browser we'll need to use a module loader. There are a few different types of module loaders such as RequireJS or SystemJS. Many people use code tools like Browserify or WebPack to encapsulate away the complexity.

For the purposes of this sample, I'm going to use RequireJS. Open up the index.html file and add this script statement:


<script data-main="requireconfig"
src="//cdnjs.cloudflare.com/ajax/libs/require.js/2.3.4/require.min.js">

</script>

This loads the RequireJS library from a remote CDN. Note that I have completely removed the script tag that loads the hello.js file. The script tag also has a different attribute named data-main with a value of requireconfig. This property tells Require that whenever it has completed loading it should look for the requireconfig.js file. Create that file next:


requirejs.config({
baseUrl: '',
paths: {
app: ''
}
});

This sets up the baseUrl and the paths to the app. Since all our code is in the main dev directory, I set these values to blank. Now, tell RequireJS to load our main application file:


requirejs(['hello']);

Since there are a few different methods of creating modules, we have to tell our TypeScript compiler which one to use. We want it to use the amd approach. When you compile your application add the module flag and specify amd. Use this at the command line:


tsc module amd hello

You'll see this:

Now load the app in the browser:

Congratulations! This series should have given you all the information you need to know to start using TypeScript to build your applications. Check out our book on Angular 4 which uses TypeScript heavily.

Keep up to date by reading DotComIt's Monthly Technical Newsletter

More Entries

All Content Copyright 2005, 2006, 2007, 2008, 2009 Jeffry Houser. May not be reused without permission
BlogCFC was created by Raymond Camden. This blog is running version 5.9.2.002.