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.

Correctly doing post-login processing in the DaftMonk AngularJS full-stack seed

So I’ve been working on a personal project using the MEAN stack (MongoDB, ExpressJS, AngularJS and NodeJS)! The nerd in me has been pretty excited to learn something completely new and different. I’ve never done full-stack development strictly in JavaScript, and so far I’m finding it to be pretty neat. I’ll be making posts about things I struggle with, or find useful, as I progress.

Anyway, I used the DaftMonk AngularJS full-stack yeoman generator (https://github.com/DaftMonk/generator-angular-fullstack) for my project seed. I definitely recommend it if you’re starting out fresh with MEAN (or even if you’re not), since it speeds up the initial setup and development immensely.

My problem arose as I was wiring up some post-processing to be done after a user logged in. In the login controller (login.controller.js), after the login function is called from the Auth service, there is a function in “.then()” that is called upon success.

Auth.login({
  email: $scope.user.email,
  password: $scope.user.password
})
.then( function() {
    //login was successful
    //...
  }

However, even though the user has logged in, the user data is not available yet! So, you cannot access the current user’s data properties (such as their role) through Auth.getCurrentUser() (for example the Auth.getCurrentUser().role field will be undefined). This is due to the fact that the data is loaded asynchronously (I’m still trying to get the hang of how that works).

The way around this is to use the Auth.isLoggedInAsync(…callback…) function. The callback sent to isLoggedInAsync is called after the user has finally been loaded, which will guarantee your post-login-processing code being executed after the data for the user is available.

This is how you’d make use of Auth.isLoggedInAsync(…):

Auth.login({
  email: $scope.user.email,
  password: $scope.user.password
})
.then( function() {
    Auth.isLoggedInAsync(function(success) {
      //Auth.getCurrentUser() will now return the user with all the properties fully loaded
    }

Enjoy!

Making a Vaadin window transparent/translucent

We had a need to do this recently, and it wasn’t obvious, so I thought I’d share.

One thing to note is that if the window is modal, this trick won’t work. Since for modal windows, Vaadin adds some more styling around the window to the back the background “dimmed”, thus giving a stronger visual focus on the modal window. For regular (non-modal) windows, this trick works great, especially if you just want to overlay some information on content behind the window.

In your java code, add the following style to your Vaadin Window:

myWindow.addStyleName("translucent");

In your theme stylesheet for your application (most likely a “.scss” file), add the following styles:

.v-window-translucent
{
  background-color: rgba(255,255,255,0.6) !important;
}
div.v-window-translucent .v-window-contents {
  background: rgba(255,255,255,0.6);
}

Then compile your theme, and refresh your page. Viola! Your window will now be translucent.

To tweak the translucency, modify the “a” (alpha) value in the rgba inside the theme style. 0.6 worked well for us, making it a bit translucent. To make it less translucent, try a value greater than 0.6. And to make it completely transparent, try 0.

Enjoy!