Notes in 9: Alternative Front-End Development

Notes in 9 180: Alternative Front-End Development for XPages

I'm on Notes in 9 again! This is my second video and one where I tried out my new microphone (which I was told was necessary). It's kind of a variety show, but highlights the beauty of a segregated application design. It also shows off a nifty side thing, which is that XPages is now a recognized language/platform/something on GitHub; my efforts in the pull request to the github/linguist repo was born from my envy of my company's newest web developer's primary background in ColdFusion (another JEE based stack, this one from Adobe) being fully set up before us; we should make the list.

This episode also highlights my ability to mis-speak. I've been working on Notes/Domino, primarily XPages, since November of 2011; I erroneously said fall of 2012 in the video. But hey, you want to see my awesome ways of code-fu, so my ability to speak English should be mildly irrelevant 😜.

The Video

Found on Notes in 9 or on YouTube (including here).

The Premise

The style of front-end development I'm demonstrating falls into the category of things we have, given by Domino, that can easily be overlooked. We can run entire web sites out of the WebContent folder. This means we don't have an XPage as our root design element, but that's not to say we are unable to do so. Since the HttpServlets I'm using (DesignerFacesServlets) run from the XPages runtime, they still pick up a logged in user's session as it's still them. If you want to look at the set up for this style, just look back at my Saga of Servlets or my GitHub repository for my App of Ice and Fire.

This doesn't take away from "traditional" XPages development, but certainly adds to it. From the perspective of a customer, a front-end heavy on industry-norm libraries/frameworks (regardless of whether you use Ember, Angular, Backbone, or others) is a more economical way than only having to hire XPages developers. One could in theory set up a git repository containing a modified version of production-like data, with a fully interactable RESTful endpoint against which a contractor can develop anything and everything in the UI portion of the app, and commit it back, with full version history and easy auditing, for re-integration into the main code base. It may take some time to set up and would rely on the fact that no server-side tasks would occur, but you could still validate the changed db.json state (or have them take snapshots, accordingly). Ultimately, it opens more doors than it closes, leaving you free for all the other concerns like governing business logic on the server-side.

A Plug

This also means that you can run faster applications, with the control that a reverse proxy like Nginx gives you. If only I knew someone who did something recently on that topic... oh wait, me! If you were one of the four (five counting Marky's cameo at the end) of us, we covered some good ground, but for those looking for the replace, check out my slide deck from my MWLUG session; there are slides and configs, including a GitHub repo of all of those things.

Announcement

The next time you see my app, it will be running on Bluemix (and likely will involve another video). Recently (Monday) we saw the 14th release of the Extension Library for Domino 9.0.1, which includes (amongst other things) the ability to control the Java permissions from a master switch or java.policy fragments. This is great news for my demo app, as it depends on the permissions being enabled for my HttpServlets to run correctly.

All in all, it's shaping up to be a good continuation of what I've already been working on. I hope you continue to find it useful, as I do. Until then, keep on Pratt keeping.