202 Lotus blogs updated hourly. Who will post next? Home | Blogs | Search | About 
Latest 7 Posts
Composing With Docker
Thu, Nov 2nd 2017 8
Hacktoberfest and More
Tue, Oct 24th 2017 7
Go Evergreen
Tue, Oct 17th 2017 13
Change is in the Air
Fri, Sep 1st 2017 10
Open Source Contribution
Fri, Jun 16th 2017 6
Docker Quick Tips
Fri, Apr 28th 2017 4
Notes in 9: Dev Tools Grab Bg
Tue, Apr 4th 2017 6
Top 10
Building Java Objects From JSON
Thu, Jan 22nd 2015 15
Go Evergreen
Tue, Oct 17th 2017 13
Task Runners pt.4
Thu, Dec 17th 2015 11
REST is Best
Wed, Sep 17th 2014 10
Eric and the Quest for More Coffee, pt.2
Fri, Jul 15th 2016 10
Git Squash
Thu, Oct 20th 2016 10
Change is in the Air
Fri, Sep 1st 2017 10
Everything Old is New Again
Mon, Oct 24th 2016 9
Notes in 9: Docker + SonarQube
Wed, Feb 24th 2016 8
Scripting Server Upgrades
Fri, Nov 11th 2016 8

Building a Front-End, pt.1
Twitter Google+ Facebook LinkedIn Addthis Email Gmail Flipboard Reddit Tumblr WhatsApp StumbleUpon Yammer Evernote Delicious

A Quick Review

I had some trepidation about this post; it revolves around the fact that I’m “completing” my blog series with multiple giant topics, on top of the one primary one I’ve focused on for the majority of this blog series. So, before we get started, I’m going to summarize a couple things. But first, a ToC:



I’ve referred to this series as #ASagaOfServlets. While most Java servlets are intended for use over HTTP (at least from a JEE, web container standpoint), this is not exclusive; I’ve used HTTPServlet as analagous to Servlet (for better or for worse).


A REST API is an architectural style of API. There is no concrete definition of what required for an API to be RESTful, but it’s best if it follows a couple conventions (previously covered); this generally boils down to:

  • a resource based interface, following HATEOAS
  • be stateless (no server session required, the URI request gives all the server needs to know)
  • be cachable or not (depending on what sort of data you’re providing)
  • work entirely independent of any particular client format (while adhering to certain things like authentication and formatted requests)

There are more that a RESTful API can do or rules that can be applied, but that’s the high level stuff. As you can see, this is part of the core of the segregation of data and primary business logic from the client-layer side of the application.

“Stack” Development

Part of my crusade in the realm of segregating application development concerns into the front-end and back-end revolves around the concept of these “ends” to the application. Both play an important role, but work best together. By building your back-end to adhere to certain conventions, you can create your front-end with any front-end technology. This is why I’m such a huge fan. At my company, we have a large number of in-house systems, many of which talk to each other. By segregating the primary business logic (governing how we store the data, events that trigger from the server, and steps in workflow) as being a part of how the server components work, then any client playing by the rules can be a valid interface; whether that’s an automated agent which checks for non-interface updates, or the front-end which contains all the user interaction at the UI level. The business logic become much more maintainable and documentable in the process.

Where XPages fits in as a component in all of this can be a little tricky. Obviously, XPages design elements encompass the application layer, but deciding how that maps to a front-end as opposed to a back-end is a bit trickier (and one I’ve complained about debated before). I don’t mean to beat up on XPages, as it offers us quite a lot of tools and components that help assemble a working app, rapidly; I can and will beat up on poorly implemented XPages application code.

XPages: Full-Stack Development?

Obviously, certain beginner XPages development approaches (those conducive to SSJS spaghetti code) can be quite the antithesis of what the segregated stack approach gives us. This makes our XPages design elements, containing not just the markup and layout of elements (fields, labels, etc.), but also logic, if(status.equals("certainStep")){ doSomethingUnique(); }, and actions (since these X conditions are true, send an email to these 12 people). Combine this with the unique, NoSQL database handling via the NotesDominoAPI, it’s my belief that XPages development is by default a full-stack application stack; for better or for worse.

Aside (talking crazy for a moment)

Some of these concepts are central to what I’ve seen previewed of the XPages (XSP) application runtime and Domino Data Service on Bluemix. That the data container being forced to be separate from the application layer isn’t just a good idea with Bluemix (which enforces the segregation of concerns as does almost any other application stack, considering that nearly all out there aren’t configured like an NSF), but means that the XPages runtime can hook into any database; something it’s already capable of, but often not done. In fact, segregating the data NSF from the application NSF isn’t a new concept either, but hey, it’s my paragraph :grinning:. I’m also fairly certain that the segregation of the XSP runtime from the other, traditional NSF components may be the gateway for us to get an updated JVM, but maybe I’m just greedy.

Ultimately, the point I’m trying to make, is that we have a lot of options and decisions we can make with Domino/XPages, but with any ambiguity, there are potential pitfalls. One way this is changing, IMO, is the bringing of the XSP(XPages) runtime to Bluemix. In case you missed it, I’ve posted a couple early thoughts on Bluemix, and I’m both impressed and excited for what it can and will bring to the table for my company and I.

Front-End Consumption

Having shaped our back-end earlier in this series to adhere to a primarily RESTful API format, we can now consume that API by some front-end. In the Notes in 9 173: Getting Started With (HTTP)Servlets video, I demonstrated this principle via the Postman REST client (a Chrome extension). There are others out there and you could even test from your command line via cURL, if you’re so inclined. What this demonstrates is that virtually any front-end can consume the API, it just comes down to how you expose/provision that API and what you point to it.

It also shows the method of data transfer. In order for a front-end to work with my RESTful API, it will need to:

  • provide/receive all data in application/json
  • stick to the available resources (houses)
  • create a new entry, one-at-a-time, against the collection endpoint (/houses)
  • read, update, delete against the (UN)ID keyed URI (/houses/[0-9a-zA-Z]{32})
  • collection data is accessible via /houses
JavaScript Consumption

Front-end development in this day and age focuses on JavaScript usage. Most people use a framework of some flavor, to automate the things they’d rather not spend too much time on. Some of these things include standardizing how you interact with an HTTP RESTful API endpoint, or automate the updating of data between bound components. The fact of the matter is, there are plenty of frameworks out there, many which can help you in your quest.

JavaScript Frameworks

Choosing a JavaScript framework can be a little daunting, if you’re doing so for the first time. There’s a long history of many web applications making use of jQuery or Dojo, both of which are libraries(/frameworks) that automate quite a bit, they’re not of the MVC/MV* flavor I’m looking for. The fact remains, one can make a fully-formed application out of either, I just won’t focus on them.

[Aside] There are jQuery UI (and mobile) and Dojox MVC, but I’m moving on for simplicity’s sake. [/Aside]

MVC/MV* Architecture

There are a lot of acronyms in framework architecture that get thrown around. Here are a couple to get you started:

  • MVC - Model-View-Controller
  • MVVM - Model-View-ViewModel
  • MVW / MV* - Model-View-Whatever

This list is far from all-inclusive, and is a bit of a side-topic to what I want to focus on here. Just remember how a model, view, and controller represent different pieces of the application pie, and all will be good.

If you want to read up more on the theory of why you would want an MVC/* framework, I recommend checking out this answer on Quora on the subject. It’s a good read which espouses the need for the a framework but as they point out, no one solution (e.g.- Backbone in their example) is an end-all, be-all.


AngularJS (as you can probably have guessed is the front-end framework I’m using) considers itself to be an MV*/MVW framework

HTML enhanced for web apps!

and has ditched the MV-something classification almost entirely.

No matter your descision on frameworks, the bottom line is that you should use one that plays to your strengths, and you should play to the strengths of the framework you choose.

Why AngularJS?

AngularJS set out to conquer some considerable hurdles when it began. The HTML5 spec was in its infancy and the front-end frameworks out there were achieving a few good things, but the Angular team wanted more.

Here are the reasons I gave for AngularJS (with some definite overlap with other frameworks) from my Chalk Talk Soup rebel slide deck:

  • bi-directional data binding (all data models by default auto-update their other references on data change, within the scope)
  • templates (via ng-include or ng-route; also ui-router, 3rd party)
  • OoB directives, services, filters, and more
  • dependency injection
  • unit testing (AngularJS was developed with e2e testing in mind, and docs examples include protractor scripts)

Here are a couple examples I had prepared for that slide deck:

Bi-directional data binding:

Dynamic templates:

Filters (out of the box!):

To add some fuel to the fire, here is a link to the Google Trends for Angular, Backbone, and Ember. As an side, check out other combinations of search terms, it can be interesting to play with; it only yields results as scraped from Google search, so it’s no absolute indicator, but interesting as it is.

For another good comparison between Angular, Backbone, and Ember, this articles does a decent job of breaking down “the good parts” and the “pain points”. The article is hosted on airpair.com, a micro-consulting site geared for developer-to-developer support, be it mentoring, code review, and more.

It’s a sign of one of the other advantages of this form of segregated, “stack” design; outside help that’s not such a closed ecosystem as the one we work in. This may not be a huge deal for those who aren’t customers, but for those who seek to at least stay afloat, it’s a decent leap towards being able to outsource without a huge amount of :dollar:.

Scary Change is Scary

Recently you may have seen David Leedy blog a link and ask for perspective on a particular post denouncing AngularJS and all its sins. All I can say is, read the comments along with the post. I personally found the post to be inconsisent with my experiences but, more importantly, ignoring certain facts and updates (which the AngularJS team does provide on a constant basis) for the sake of their argument. Make up your own mind, but be informed.

A Note on Version 2

AngularJS version 2.0 takes advantage of ECMAScript 6 and follows a format considerably more like web components. This means that it will fit in well with the final release of the HTML5 spec. It’s also on the early side and as the AngularJS 2.0 site points out,

Angular 2 is currently in Developer Preview. We recommend using Angular 1.X for production applications.

For now, I’m rocking the 1.x line, specifically staying in 1.3.x for my current app. A lot of people are trying to make a big deal out of Google’s choice to break 2.x from 1.x, but the fact of the matter is that 1.x isn’t going anywhere just yet and will have a stable branch for quite some time to come. I first started dabbling on AngularJS 0.9.8, and started grasping much more of it after 1.0 hit. If I was so inclined, there is a stable 1.0.8 release available right on angularjs.org including documentation at that level, and 1.0.8 was released Aug 22nd, 2013.

So, all those naysayers, I say pick a framework. I’m going with AngularJS and it’s been pretty pimp so far.


Come back tomorrow for the conclusion of this epic journey.

Jun 16, 2015
3 hits

Recent Blog Posts
Composing With Docker
Thu, Nov 2nd 2017 2:00p   Eric McCormick
Background About a year ago, I blogged on automating server upgrades with Docker and a BASH script. This met the needs I had at the time, and worked itself out to be pretty stable. But, since I think about such things and always question my preconceptions, I went down a path of creating a Docker compose config file, something I wouldn’t have had to create from scratch by waiting a little while as one appeared as an example from GitLab. As it turns it, it was a great learning experience regardl
Hacktoberfest and More
Tue, Oct 24th 2017 2:00p   Eric McCormick
Hacktoberfest 2017 October brings many good things with it. It’s the beginning of autumnal colors here, along with some yard raking in my case. It also brings with it not just Oktoberfest, but Hacktoberfest! Hacktoberfest 2017 Hacktoberfest is a month long open source support initiative, sponsored by Digital Ocean, partnering with GitHub. It’s meant to promote open source involvement and contribution. As added incentive, if you meet the criteria, you can get a free t-shirt (and stickers).
Go Evergreen
Tue, Oct 17th 2017 4:00p   Eric McCormick
Happy 🎂 Day IE 11! On the 17th of October in 2013, Internet Explorer 11 was released from Microsoft. That means that as of today, this popular* browser is now four years old and, with all respect to it, it really ought to go. Good day sir. I said good day! Evergreen Browsers What makes a browser, or any software for that matter, evergreen? Well, the basic requirements for a browser, or any piece of software for that matter, are specifically the support of automatic updates, that bring in:
Change is in the Air
Fri, Sep 1st 2017 1:00p   Eric McCormick
I’m Back What Can I Say? In Case You Missed It If you find yourself asking “where was Eric?”, this should summarize it all: Instead of trying to do everything all summer, I tend to take a break from blogging and a lot of open source endeavors over the summer. It means I can focus on family time along with yard and house projects. Ah... Summer That’s all paid off and, with fall fast approaching, I’ve found myself wanting to start those things back up; ramping up into winter when
Open Source Contribution
Fri, Jun 16th 2017 5:00p   Eric McCormick
Intro It’s time to clear some of the backlog. I started this post a few months back and it should probably be sent on its way to clear the pile of drafts I haven’t finished yet… 🤔 I have a bit of a passion for open source software. My preferred distribution of Linux has been Ubuntu since 4.10, the Warty Warthog (I was even a minor contributor on a short lived, wildly popular project that aimed at improving the Ubuntu experience early on), I’ve enjoyed most open source projects I’ve
Docker Quick Tips
Fri, Apr 28th 2017 3:00p   Eric McCormick
Docker If you have been living under a rock, Docker is pretty much amazing. If you haven’t been living under a rock, you may be getting used to the idea of Docker, but still have the occasional question. I’ve found myself using Docker in increasing amounts and complexity over the last year or so. I’ve recently decided to start recording some of the tasks I’ve found useful, some of which may be less familiar to a beginner. If you’re so inclined, check out the playlist, embedded here.
Notes in 9: Dev Tools Grab Bg
Tue, Apr 4th 2017 1:00p   Eric McCormick
Intro I’m on Notes in 9 again, with a “grab bag” of a couple of tools I’ve put together recently that may be of a varying degree of useful for other Domino + XPages developers. You don’t need these to do development, but for the right person, they may help with their development workflow. Also of note, with the upgrade to Swiper with the FP8 release of Notes + Domino Designer, the limitations previously mentioned are no longer there! This means that my second tool I talked about, node-
Custom JSON Serialization With GSON
Mon, Jan 23rd 2017 2:00p   Eric McCormick
Intro Here’s a curious one, in which I found myself with a limitation of not being able to output JSON with scientific notation values. wait, what? If you’re wondering why that is, since both JSON and JavaScript allow scientific notation of number values, you are absolutely correct and that’s a great question. The strange thing was that I found myself outputting perfectly valid JSON to be consumed by something specific which didn’t allow scientific notation. I’m not entirely sure wh
Recapping 2016
Mon, Jan 16th 2017 3:00p   Eric McCormick
Intro Per usual, I’ve had a little break between things and decided to catch up with a bit of a summary of some recent things that each didn’t necessitate their own post. 2017 IBM Champion For starters, I’m honored to be named an IBM Champion in Collaboration Solutions (/ Social Business) for the third time. This would be a hat trick in (ice) hockey 🏒. I’m happy to be recognized with a group of people, developers and more, who are passionate about both their work and the plat
Scripting Server Upgrades
Fri, Nov 11th 2016 12:00a   Eric McCormick
Intro This one might be slight departure from my usual, but those that have followed my blogging this past year will have noticed a bit more of a leaning towards DevOps in some of my posts. This echoes a lot of what I’ve been concluding as increasingly a necessary part of development; that we need to consider a picture large enough to encompass the themes surrounding development functions and, like any good developer (DRY ~= “lazy”), automate the heck out of it. Overview I had previously

Created and Maintained by Yancy Lent - About - Planet Lotus Blog - Advertising - Mobile Edition