MEAN stack foreign language translations

For the MEAN application I’m currently building, there is a requirement to have it served in multiple user-selectable languages. I used the MEAN fullstack generator (https://github.com/DaftMonk/generator-angular-fullstack), which does not provide i18n (internationalization) support.

When setting up my application for i18n, I realized that I needed translations available up and down the stack. So not just in the View, also in the Model and Controller. I ended up using angular-translate (https://github.com/angular-translate/angular-translate) and MomentJS (https://github.com/moment/moment/) in the client side AngularJS. And I created my own custom solution, very simple, in Node for the server side model and controller.

I think angular-translate works great in Angular, and there are plenty of guides around so I won’t go into it. But I want to mention that angular-translate doesn’t have great support (at least that I could find) for translating dates and numbers. This is where MomentJS can fill in the gaps. Again, plenty of guides out and good documentation out there for MomentJS.

For Node, I created a module that simply has a JSON of all the translations, and a function that returns the translation. Example below:

—translations.js—

'use strict';
var en = {
  VERIFICATION_EMAIL_SUBJECT: 'Sign up verification',
  VERIFICATION_EMAIL_TEXT: 'You are receiving this email because you or someone else has signed up with this email address (%s)',
};
var fr = {
  VERIFICATION_EMAIL_SUBJECT: 'S\'inscrire vérification',
  VERIFICATION_EMAIL_TEXT: 'Vous recevez ce courriel parce que vous ou quelqu\'un d\'autre a signé avec cette adresse email (%s)',
};
module.exports.get = function(lang, key)
{
  if(lang == 'en')
    return en[key];
  else if(lang == 'fr')
    return fr[key];
};
module.exports.en = en;
module.exports.fr = fr;

And then then use it like so:

var translations = require('translations');
console.log(translations.get('en','VERIFICATION_EMAIL_SUBJECT'));
console.log(sprintf(translations.get(user.language,'VERIFICATION_EMAIL_TEXT'),'blah@blah.com'));

This way translations can be available anywhere on the server side that uses Node.

The power of AWS Elastic Beanstalk Environment Configuration using .ebextensions

This is a quick post exploring the usefulness of AWS Elastic Beanstalk Environment Configuration files using “.ebextensions”.

.ebextensions config files, written in YAML (http://yaml.org/), can be used to set up the server platform by automatically performing various custom actions and configuration when an application is uploaded to AWS Elastic Beanstalk.

Through .ebextensions you can:

  • Create configuration or other files (SSL certificates, etc) on the server machine
  • Install packages/programs
  • Start/stop services
  • Execute custom commands
  • And much more

This can help you set up a new or existing server, as far as the configuration on the server machine is concerned, without manually having to do it yourself every time you deploy a new application.

Since I’m most familiar with how .ebextensions work using Java .war’s deployed to AWS Elastic Beanstalk, here’s a quick rundown on how to set it up for your Java environment: in your web project’s WebContent folder, create a folder called “.ebextensions”. Then within the .ebextensions folder you can create one or many files ending with a .config extension. Any and all .config files within the .ebextensions (ProjectRoot/WebContent/.ebextensions/*.config) will get executed after you upload the .war file for your project to AWS Elastic Beanstalk.

So if you’re using AWS Elastic Beanstalk and aren’t yet using .ebextensions, I would highly recommend you look into it. There is more documentation here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html

Vaadin: Executing custom JavaScript from a thread, or loading custom JavaScript functions into global scope

As you may know already, in Vaadin you can use com.vaadin.ui.JavaScript.getCurrent().execute(…) function to execute some custom JavaScript on the client browser.

  1. Executing custom JavaScript from a thread:
    The above works well as long as the JavaScript execute() method is being called on the main UI thread. However, if JavaScript.getCurrent().execute() is called from a background thread, the JavaScript won’t get executed until there is a periodic refresh of the UI, or there’s a UI event (triggered by the user, such as a mouse click somewhere). This can seem to cause erratic behavior, with the JavaScript executing at unpredictable times. (Side note: any Vaadin UI access/manipulation from a background thread needs to be done inside com.vaadin.UI.getCurrent().access(new Runnable() { … });, and also note that you want to do your time-consuming heavy lifting first (such as retrieving data from the back end) and then go into UI.getCurrent().access(…) to manipulate the UI).To get around this problem, simply use Vaadin Push. You’ll need to enable push if not already (see Vaadin documentation on how). Then depending on the push mode you’ve used (manual or automatic) you’ll either need to call com.vaadin.ui.UI.getCurrent().push() or not (for manual mode you’ll need to call the push() method, for automatic mode it will be called after the runnable you send to the UI.access(…) method finishes executing). So call get JavaScript.execute(…), and then UI.push() last. Example:

    new Thread() {
        public void run() {
            //some long running background work
                 UI.getCurrent.access(new Runnable() {
                public void run() {
                    JavaScript.getCurrent().execute("alert('Background Task Complete!');");
                                UI.getCurent().push();
                }
            });
        }
    }.start();
  2. Loading custom JavaScript functions into global scope:
    This is extremely useful so you can define a JavaScript function which you can use later from JavaScript.getCurrent().execute(…), such as inside an event (a button click, for example). However, the JavaScript function will need to be in the global scope by injecting it into thetag for the HTML page served by Vaadin. To do this, use the following code while your Vaadin view is being created, or is being enter()’ed.

    StringBuilder script = new StringBuilder(); script .append("var head = document.getElementsByTagName('head')[0];") .append("var script = document.createElement('script');") .append("script.content='function sayHello() { alert(\"Hello!\");}';") .append("head.appendChild(script);"); JavaScript.getCurrent().execute(script.toString());

    Note: as I mentioned, a JavaScript function can only be loaded this way when the view is being created, or in the view’s enter() method. To create a function this way AFTER the page is already loaded (such as through some event), you’ll need to use Vaadin Push, and call UI.getCurrent().push() after the JavaScript.getCurrent().execute() even though you’re not on a background thread.

  3. You can define a function in the script tag being created above, which can then be called later on through JavaScript.getCurrent().execute(“sayHello();”); perhaps inside a Vaadin button click listener.

Enjoy!

Getting rid of Jetty related exceptions when using Vaadin Push with Tomcat

At least in Vaadin 7.3.x and 7.4.x, running on Tomcat with Push enabled, you may see several exceptions in your console having to do with Jetty. Even though you’re not using Jetty, this is happening because Vaadin is getting tricked into assuming that Jetty is being used, since a Jetty library is found in the Java classpath.

Vaadin does realize after the exceptions that Jetty isn’t actually there and continues gracefully. But though these exceptions are harmless, they’re still unsettling to constantly in your tomcat logs. As I mentioned, this is happening because there is some Jetty library in your Java classpath. So thus the obvious solution get to rid of these exceptions is to remove all Jetty libraries from your Java classpath. Search for any .jar’s that have “jetty” in the name, and remove them.

If you’re using Ivy or Maven dependency management, the library may be downloaded as a sub-dependency from another dependency. You will need to go through all your dependencies to check which ones also reference Jetty. The culprits in our case were vaadin-client-compiler and HtmlUnit (both reference Jetty for Jetty related things, but since we’re not using Jetty anyway, getting rid of the Jetty library should cause no harm).

We use Ivy, and I found how to exclude certain sub-dependencies, which is simple. Use the  tag in your ivy.xml wherever jetty is a sub-dependency. A example follows:

<exclude org="org.eclipse.jetty" name="*" />

And viola! No more random Jetty based exceptions from Vaadin.

AngularJS creating multiple $resource endpoints in a service

So this had me baffled for a bit. For using Angular’s $resource in your Angular service, you map it to a particular URL with (optional) parameters defined for that URL. Then how can you have multiple resources with their own unique URLs mapped in the same service?

For example, here’s a service called User which maps to the URL “/api/users/…”:

angular.module('myApp')
  .factory('User', function($resource) {
    return $resource('/api/users/:id/:controller', {
      id: '@_id'
    }, {
      changePassword: {
        method: 'PUT',
        params: {
          controller: 'password'
        }
      },
      get: {
        method: 'GET',
        params: {
          id: 'me'
        }
      }
    });
  });

As you can see, there’s one resource in this service that maps to the one URL, so then how can I add another URL for the $resource?

The answer turned out to be pretty simple, actually. What you have to do is create an object (JSON) of $resources that are returned for the service. You can have individual elements inside the object that each map to a different $resource. So, for example:

'use strict';

angular.module('myApp')
  .factory('User', function ($resource) {
    return {
      WithId: $resource(
        '/api/users/:id/:controller',
        {
          id: '@_id'
        },
        {
          changePassword: {
            method: 'PUT',
            params: {
              controller: 'password'
            }
          },
        }
      ),
      Misc: $resource(
        '/api/users/misc/:controller',
        null,
        {
          generateResetPasswordToken: {
            method: 'POST',
            params: {
              controller: 'generateResetPasswordToken'
            }
          },
        }
      ),
    };
  });

In the above example, in the “User” service, we have two resources that can be accessed. To access “changePassword”, we can use User.WithId.changePassword (which maps to a particular URL), and to access “generateResetPasswordToken” we use User.Misc.generateResetPasswordToken (which maps to another URL).

Voila!

Adding an asterisk to required fields in Bootstrap

This is pretty useful in giving a visual indication to the user when a form field is required.

The CSS:

.form-group.required .control-label:after {
  content:"*";
  color:red;
}

Then in your HTML:

<form>
  <div class="form-group required">
    <label class="control-label">Required Field</label>
    ...
  </div>
</form>

There will now be a nice little “*” after the label for “Required Field”.

Making a pseudo div fade in using CSS animation

The example I’ll use applies specifically to Vaadin, for when the loading bar is shown if the server is taking too long. However, the same CSS styling I’ll use can be applied to any pseudo div.

When Vaadin loads a page (or a “view”), and if the page takes too long to load, there’s some client side JavaScript and CSS that Vaadin pre-loads, which displays a loading bar or progress bar. This bar progresses forward, from left to right, at the top of the page, under the “URL” area of your browser. And it eventually goes away when the page loads. This gives the user the indication that something is happening and they should wait.

If the page takes too long to load, this bar eventually starts blinking. And if the server is stuck (had a hiccup somewhere), this bar just blinks forever. After some waiting, more adept users eventually realize it will never load and they refresh the page which usually resolves the issue. However less tech-savvy users don’t know what to do at that point. So we set up a small message box (a pseudo div) that floats under the loading bar, which tells the user to refresh the page. This is kind of like what the GMail web app does when there’s a network issue.

First of all, to set up the pseudo div, we add the following to our theme’s scss (SASS) file that Vaadin uses:

.v-loading-indicator-wait:after
{
  position:fixed;
  content: "Temporary Internet issue... Please wait, or refresh page.";
  color: black;
  background-color: #F9EDBE;
  border-style: solid;
  border-color: #F0C36D;
  box-shadow: 2px 2px 5px #888888;
  left: 50%;
  transform: translateX(-50%);
  top: 10px;
  padding-top: 5px;
  padding-right: 5px;
  padding-bottom: 5px;
  padding-left: 5px;
}

“v-loading-indicator-wait” is the style Vaadin gives to the loading bar which shows up after a certain amount of waiting while the server is processing the request. So to show our floating div with the loading message, we can use the ::after (v-loading-indicator-wait::after), as indicated above.

The problem is, that the v-loading-indicator-wait is added after just a number of seconds of waiting (around ~5), and showing the floating div would be too soon. So the best way (or at least an easy way) to do it is to use animation to delay when it is added.

You can define the animation to “fade in” the div (from being invisible to visible) after a certain number of seconds, like so:

@include keyframes(animate-in-scale-up) {
  0% {
    @include transform(scale(0));
  }
}

@-webkit-keyframes fadein {
  0% { opacity: 0; }
  80% { opacity: 0; }
  100% { opacity: 1; }
}

@-moz-keyframes fadein {
  0% { opacity: 0; }
  80% { opacity: 0; }
  100% { opacity: 1; }
}

@-o-keyframes fadein {
  0% { opacity: 0; }
  80% { opacity: 0; }
  100% { opacity: 1; }
}

@keyframes fadein {
  0% { opacity: 0; }
  80% { opacity: 0; }
  100% { opacity: 1; }
}

.v-loading-indicator-wait:after
{
  //...all the other stuff
  -webkit-animation: fadein 12s ease 1 normal;
  -moz-animation: fadein 12s ease 1 normal;
  -o-animation: fadein 12s ease 1 normal;
  animation: fadein 12s ease 1 normal;
}

And viola. The floating div doesn’t show up until about 12 seconds after the “v-loading-indicator-wait” is added, which is about 5 seconds after a request is initiated and the server hasn’t responded. So that’s a total of 17 seconds between the user initiated the request and till when the message shows, which I believe is enough waiting time to realize the server may never respond.