193 Lotus blogs updated hourly. Who will post next? Home | Blogs | Search | About 
 
Latest 7 Posts
Custom JSON Serialization With GSON
Mon, Jan 23rd 2017 5
Recapping 2016
Mon, Jan 16th 2017 8
Rebirth: An App of Ice and Fire
Wed, Dec 14th 2016 7
Scripting Server Upgrades
Fri, Nov 11th 2016 6
Everything Old is New Again
Mon, Oct 24th 2016 7
Git Squash
Thu, Oct 20th 2016 5
MWLUG Success
Wed, Aug 24th 2016 7
Top 10
Building Java Objects From JSON
Thu, Jan 22nd 2015 22
Redmine, CodeRay, and Domino, Oh My!
Mon, Aug 11th 2014 10
Enhanced Editors
Fri, May 27th 2016 10
Git History Searching
Tue, Jul 12th 2016 10
Fixing Dojo 1.6.1 in Domino 8.5.3
Tue, Sep 2nd 2014 9
When You Need a Comparator
Thu, Jan 8th 2015 9
Notes in 9: Docker + SonarQube
Wed, Feb 24th 2016 8
IoT and Raspberry Pi
Fri, May 20th 2016 8
Recapping 2016
Mon, Jan 16th 2017 8
Notes in 9: Highlights From My IBM Connect Session
Tue, Jun 28th 2016 7


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:

Contents


Servlets

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).

RESTful API

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.

FWIW

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.

Tomorrow

Come back tomorrow for the conclusion of this epic journey.



---------------------
https://edm00se.io/xpages-servlets/building-a-front-end-pt1-a-quick-review
Jun 16, 2015
3 hits



Recent Blog Posts
5
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
8
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
7
Rebirth: An App of Ice and Fire
Wed, Dec 14th 2016 4:00p   Eric McCormick
Intro If you read my blog for any of the Saga of Servlets series, then I hope that you’re excited I’m returning to the application I put together for it. This time, it’s as a conversation piece in regards to some of the build process modernization I engaged in recently, in order to unify the code base in its git repository. In any case, it’s helping pave the way forward before I update some of the back-end elements, when it will again be a talking point for some additional rework and
6
Scripting Server Upgrades
Fri, Nov 11th 2016 2:00p   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 p
7
Everything Old is New Again
Mon, Oct 24th 2016 8:00p   Eric McCormick
Intro Every so often, it’s good to reassess one’s position. This is good from both a standpoint of being inquisitive and even interrogative, but when it comes to the ever changing landscape of the front-end development space, it’s not only inevitable, but must be embraced for what feels the need to “stay afloat”. I’m changing theme of my blog, hopefully for the better. The previous theme was good and did a great job of getting things started, but while I had forked a copy of a good
5
Git Squash
Thu, Oct 20th 2016 8:00a   Eric McCormick
Intro If you’re just here to learn a little about how to “squash” commits with git, skip down a ways. Otherwise, hold on, and I will catch you up on a couple of personal notes before we get there. On the Blog It’s been a little while since I blogged last. This has been due to a combination of reasons; specifically, I’ve been busy with: my family, it was the end of summer with lots of things going on a number of projects around the house (a deck removal and basement remodel
7
MWLUG Success
Wed, Aug 24th 2016 8:37a   Eric McCormick
Intro MWLUG was a great success as far as I’m concerned. Each time I’ve gone I’ve had the great enjoyment of being able to attend some high quality sessions, meet with lots of colleagues and friends from the community, and get a view into products and solutions many people are undertaking, over conversations and interactions outside of the sessions. This is always a great way of interacting with others who were able to make it. Unlike the IBM conference of Connect(EDsphere), this is purel
2
Manually Renewing HTTPS w/ Let's Encrypt
Wed, Jul 27th 2016 10:40a   Eric McCormick
Intro A while back, I rolled a personal project, which is a Node app, to Bluemix for lightweight use. I managed to make use of Let’s Encrypt for the HTTPS certificate, but only after realizing that there was a bit of a manual aspect to it that is the antithesis of an automated script for such things. Ultimately, after finding some information in a blog post form Marky Roden (of all people), I was able to get moving. The only downside wound up being that time passed, and it came time to renew
6
Eric and the Quest for More Coffee, pt.2
Fri, Jul 15th 2016 4:17p   Eric McCormick
Posted in the “aside” category. Submissions There were three submissions via the Google Form, and a couple more form messages via social media. Honestly, I had debated either a nondescript or far more overt mug w/ the likeness of one of the more iconic of H.P. Lovecraft’s imaginations, but this seemed a bit over the top. Suggested were: a replacement for my alma matter a Go Army, Beat Navy mug (which was never my thing) this gem from shop.Scotch.io (again, pretty overt)
10
Git History Searching
Tue, Jul 12th 2016 10:00a   Eric McCormick
First, A Shout-Out The recording of the session called “Normalizing XPages Web Development” that Shean P. McManus and I gave at the 2-day, virtual ICONUS (formerly IamLUG) event this year is now available from “Archive and Replays”. If you missed it, I recommend checking it out, it’s a great benefit of ICONUS and I hope that those who did get a chance to attend enjoyed the subject material. We covered a lot of ground and were able to demonstrate what is, in my opinion, one of the grea




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