AngularJS and Domino – Setting the Scene

Along  with Marky Roden and Steven Chapman I am going to blog over the next few weeks about AngularJS and Domino Development.  The idea between us we will give out enough information to wet your appetite.

I am not going to cover why you might want to look at AngularJS – hopefully Mark and others have got you interested.

My approach to leveraging JavaScript frameworks and AngularJS is to consider the Domino Server as just another service in the stack, the idea being it gives maximum flexibility to the business from an IT strategy but also helps you as well ;-)

To that end I am just going to outline how the architecture might look.

Architecture

Up to now I suspect a lot of people have used Domino as an all in one solution, which is fine and does provide value but my approach going forward is to break away from doing everything in Domino, instead I am going to just use the Domino Server as a resource for Authentication, data storage and in some cases application logic.  Depending on your architecture the Domino Server will only be providing JSON data and static HTML files.

One of the advantages of this approach is you can swap out the Domino server (sacrilege I know) for an alternative server at some point in the future without having to change your UI – assuming you can generate the same JSON data.

This is how the architecture would look in this case:

suggestarchitecture

NodeJS is just an example (though a very good one) but you could swap that for other Application Servers.

The concept being your application server can access a collection of services using a REST API which returns JSON, which in turn serves the JSON data, HTML templates and static files to the browser.  Once it hits the browser AngularJS takes over and builds and controls the UI.  You still have full control over the markup it just provides a helping hand.

It might be that for you NodeJS is not required because your going to use Domino as an application server but you still want to separate the HTML Server aspect (say use a CDN like Amazon) in which case it might look like this:

dominohttp

In this case the Domino Data is sent direct to the browser over HTTP (its still JSON data), again the guts of the application are built client side using AngularJS.

The issue with this approach is the Cross Domain problem – I have talked about this in the past and mentioned using CORS which works ok with the browsers that support it.  The problems cones when you try to use Session based Authentication – I think Mark Roden is going to discuss this issue later, if not I will.

For learning about AngularJS and Domino I am going to suggest you  keep everything on the Domino server to remove any cross domain issues whilst learning, so something like this:

dominoarchitecture

There are other ways to generate JSON data from Domino but typically the Domino Data Service and XAgents are how I generate the vast majority so these are the 2 methods I will concentrate on when providing examples.

IDE

webstorm_logo

Mark has already mentioned Webstorm and frankly if your serious about Web Development then you would be mad not to get it.  At the very least grab the 30 day trail and forget about DDE for a while (its like going on holiday).

In addition I recommend you use Chrome as you main browser when doing AngularJS work install the Chrome plugin – AngularJS Batarang.  You will not need it initially but comes in handy later on.

Setting up the Development Environment

Ok the assumption is you have Webstorm and you want to use Domino, I suggest you use Domino 9 – or at the very least have a version which has the Domino Data Services running.  Remember we are building our environment to take advantage of the Domino Security without having to worry about cross domain issues.

The key thing to make things simple is to either have the Domino Server installed locally (best case) or have a drive mapped to the Domino \ Data \ domino \ html folder on the server.  Either way as far as Webstorm is concerned you are saving your working files directly in the folder of the webserver – No FTP, No WebDav just a simple folder.  You can and should still have Source Control enabled – either through Webstom or through an external tool like SourceTree.

Assuming you have that HTML folder access this how you configure Webstorm to take advantage of it:

First Create a New Project

Notice I have the Domino Server installed locally so I am creating my project within the html folder.

image

Configure Deployment Configuration

image

Add a new deployment configuration using the + and select In Place

image

Make sure the configuration is selected as the default (the tick at the top) and change the URL to whatever your server is.  You can leave it localhost but I prefer to have a fixed IP for my machine and use that.

image

Change the Mappings to include the folder (project) name – because this is how the Domino Server will reference that folder.

image

Create a Test Page

Right click on your project and select New > HTML File – call it something sensible like index

image

Now you can either preview the page or start debugging.  The live editing mode of Webstorm only kicks in if you use the debugger so we will do that.

image

The browser should open with a Yellow bar displayed indicating JetBrains IDE Support is debugging.

image

Now try changing the HTML page – add a h1 to the body or something.

image

As you type the browser will automatically display the content – no need to save or refresh the browser.

Hopefully you now have Webstorm configured and running – next time I will get into using AngularJS, I will be covering loading Data from Domino Data Services, Forms, Handling Domino Authentication and other goodies.

To keep you going Steve and Mark are both publishing AngularJS blogs today.