December 2014 | All of the Nerdy Acronyms!

GWT is Google’s open source set of tools to develop and debug ajax enabled web applications. GWT applications are written in Java and then compiled into Javascript.

The following article shows how to compile and deploy the sample GWT project in Eclipse 4.3/4.4 and can be downloaded here. For the sake of keeping this relevant to a broader group, I will be assuming basic level Java and Eclipse experience.

1. Setting Up Your Environment

There are a few Eclipse SDKs and browser plugins you’ll need to install in order to start developing GWT applications. To do this, navigate to Help > Install New Software. Depending on your version of Eclipse, you’ll need to enter the following into the “Work with:” dropdown:

4.3 – https://dl.google.com/eclipse/plugin/4.3
4.4 – https://dl.google.com/eclipse/plugin/4.4

You’ll want to check Google Plugin for Eclipse and SDKs to install the corresponding plugin/sdk for your Eclipse version.

2. Create Your Web Application

Once your environment is setup, you can birth your new GWT project. In Eclipse, navigate to File > New > Other. You’ll be prompted with a New Project Wizard. Expand the Google folder and select Web Application Project.

Enter a name for your project. For this example, I chose DemoApp.

Next, you’ll enter a Package. I chose com.demo.demoapp. This determines your folder structure in the src folder of your project. In this example, the folder structure would be /src/com/demo/demoapp.

Uncheck Generate project sample code. The sample code provides a very nice starting point, but does include some fairly advanced Java code (interfaces, implementations, etc). I would recommend checking out the sample code provided once you have a firm grasp of how GWT operates.

All other settings should be correct as default. Location determines which Eclipse workspace to use. Google Web Toolkit and Google App Engine under Google SDKs allows you to specify a particular version of each.

If you are deploying to Google App Engine and have already setup your Application ID, you can enter it here. Otherwise, you can leave this blank for now. It will be touched on later in this article.

3. Project Source

A GWT application can be separated into 2 parts, Server and Client. Technically, it could be separated into 2.5 parts if you count code that is used for the server and client (shared), but for the sake of brevity, we’ll focus on the 2 distinct parts.

Your server code can be found in your package directory. Using the settings from above, this example’s server code can be found at /src/com/demo/demoapp.

By the time you finish this section your project directory structure should look similar to this:

/src
--/com
----/demo
------/demoapp
--------DemoApp.gwt.xml
--------/client
----------DemoApp.java
--------/server
--------/shared
/war
--DemoApp.html

Create a folder for each area of your code. Within the /src/com/demo/demoapp folder, I created a server and client folder. For code that would be used by both, a shared folder would be useful, but we wont be putting anything in that in this example.

Create your Entry Point Class

The main entry point for the client side of things is within the file named after your project, DemoApp.java. In this example, I created this file in the client directory. This class implements the EntryPoint class. Within this Java class, we will create the method onModuleLoad(). Upon loading, this method is called automatically. In this example, we will use this entry point to create our user interface and event handlers.

Here is our entry point in full:

package com.demo.demoapp.client;

import com.google.gwt.core.client.EntryPoint;

public class DemoApp implements EntryPoint {
    public void onModuleLoad() {
    }
}

Create your Module XML

Next we will need to create a Module XML file detailing some things about our project. This will be named DemoApp.gwt.xml and it is placed in your package directory (/src/com/demo/demoapp). Obviously, DemoApp would be named after whatever your project name is. Here are the contents of our simple Module XML file. The parts relevant to your project have been marked in bold.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.6.0//EN"
 "http://google-web-toolkit.googlecode.com/svn/tags/2.6.0/distro-source/core/src/gwt-module.dtd">

<module rename-to='demoapp'>
 <!-- Inherit the core Web Toolkit stuff. -->
 <inherits name='com.google.gwt.user.User'/>

 <entry-point class='com.demo.demoapp.client.DemoApp'/>

 <!-- Specify the paths for translatable code -->
 <source path='client'/>
 <source path='shared'/>
</module>

Create your HTML Host Page

Our last step is to create a frontend to connect our fancy Java EntryPoint class to. These are called HTML Host Pages. These sound fancier than they really are. An HTML Host Page consists mostly of basic HTML. It can have references to your stylesheets, scripts, etc.

To start creating HTML Host Pages, you will need to create a war directory at the root of your project. Not in your package. This is where you would keep your static resources (scripts, css, etc). GWT also stores it’s compiled static resources here as well in a subfolder named after your project. For example, /war/demoapp.

For our very basic HTML Host Page, we will use the following:

<!doctype html>

<html>
  <head>
    <script type="text/javascript" language="javascript" src="demoapp/demoapp.nocache.js"></script>
  </head>

  <body>
    <div id="demoapp_main"></div>
  </body>
</html>

The most important thing to notice is that we are referencing the script myapp/myapp.nocache.js. This file will be created when we compile our project.

You could compile your project with just the entry point class and module XML before creating your host pages, but for the sake of keeping things in order, I explain the compile process after you master the ancient art of the HTML Host Page.

The next point of interest is the div with the id of demoapp_main. Going back to our entry point class, we can reference elements in our host page using their ID attribute.

Our new entry point class could look like this. New code has been highlighted in bold.

package com.demo.demoapp.client;

import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.RootPanel;

public class DemoApp implements EntryPoint {

	public void onModuleLoad() {
		final Button btn = new Button("Demo Button");
		RootPanel.get("demoapp_main").add(btn);
	}
}

All we are doing here is creating an instance of a button and adding it to our demoapp_main div from our HTML host page and attaching a click event to it.

We are now ready to compile and deploy.

4. Compile

To compile a GWT application in Eclipse, you right click on your project name and select Google > GWT Compile. You’ll be presented with the option to set a specific log level and the option to change the output style of the compiled Javascript. For now, leave these as default.

If you ever need to add compiler/VM arguments, you can expand the Advanced section and enter them there.

If any changes are made to any of your package code, you will need to compile your project again.

5. Deploy

Deploying locally to debug
To debug locally, you click on Run > Debug As > Web Application. If this is your first time viewing a GWT application locally, you will be prompted to download the GWT plugin.

At the time of writing, the plugin doesn’t seem to support Firefox versions higher than 26. Unfortunately, my Firefox was version 34 so I had to resort to Chrome.

Deploying to Google App Engine

If you are setup to use Google App Engine, you can deploy directly to it using an Application ID that has been setup in your Google App Engine console.

To set your project up to deploy to Google App Engine, right click on your project name and navigate to Google > App Engine Settings and enter your Application ID under Deployment. Hit Ok and right click on your project name and navigate to Google > Deploy to App Engine. Your project should then open up as the address app.appspot.com.

Upload to Host

If you want to deploy to your own server, simply upload the contents of the /war folder to your host of choice.

Introduction

meteor.js is a library that allows you to make real-time web applications from start to finish without any other supporting libraries or tools. When you install meteor.js, you get everything you need to develop both the client and server side of your application. That’s quite a big deal in this age of being faced with having to cherry pick from the many client/server-side technologies available today for your application.

The downside to using meteor.js is that it requires a server to be running the meteor process. So if you have any sort of VPS (Virtual Private Server) hosting (HostMonster, DreamHost, etc), then you may need to build your meteor app elsewhere.

For the sake of this post, we will be deploying to meteor’s free development hosting option.

Installing

From your terminal of choice (mac, SSH, etc), simply install meteor.js via curl like so:

curl https://install.meteor.com/ | sh

For windows, you can download the installer https://www.meteor.com/install. If you are doing this in a shared environment, such as a site on HostMonster, you’ll end up with a warning message with a few options.

Couldn't write the launcher script. Please either:

(1) Run the following as root:
cp "{Environment Specific Path}/.meteor/packages/meteor-tool/1.0.35/meteor-tool-os.linux.x86_64/scripts/admin/launch-meteor" /usr/bin/meteor
(2) Add "$HOME/.meteor" to your path, or
(3) Rerun this command to try again.

Typically, due to not having root access, your best bet is #2. Note: the areas bolded above may be different in your environment. Adjust accordingly. To do this, type this in your terminal window:

PATH=$PATH:$HOME/.meteor

You can test this right away by typing meteor in your terminal. If you were successful, it will give you a warning about not being in a project directory. This only changes the path for this particular terminal session. If you want to make it more permanent, you can edit your .bashrc file. My .bashrc file is located at ~/.bashrc and look something like this after adding the meteor path to it.

alias php="php-cli"
export HPATH=$HOME
export PATH=$PATH:$HPATH/.meteor

Deploy Your First meteor.js Application

Navigate to the directory you want to create your first meteor.js application. In my case, I created a subfolder in my public_html directory. Once there, create your first app:

meteor create project-name

meteor.js will do it’s thing and after a few seconds, your barebones meteor app will be ready to go. By default, meteor will create a build directory (.meteor), and html, css, and js files. Depending on your meteor version you may get slightly different contents in your html/js.

At this point you can deploy your project to meteor’s free hosting by typing

meteor deploy project-name.meteor.com

and after a few prompts, your project will be visible at http://project-name.meteor.com.

Applying Some meteor.js Fundamentals

Once you’re done basking in the glory of your first published meteor app, we will start poking at the html/js files. In your html file, you will see an example of meteor’s template structure.

<body>
  {{> hello}}
</body>

<template name="hello">
  <h1>Hello World!</h1>
  {{greeting}}
  <input type="button" value="Click" />
</template>

{{> hello}} will output the contents of everything inside of <template name="hello"></template>. Inside the hello template that there is a template variable named greeting. This corresponds to some code in the project-name.js file.

if (Meteor.isClient) {
Template.hello.greeting = function () {
return "Welcome to demo.";
};
...
}

You can have regular javascript variables, but in order to make it a template variable it can be created a variety of ways.

Template.hello.greeting = function() {
return 'This is a greeting';
}

//-- standard javascript variable
var foo = 'This is foo.';
//-- ..turned template variable
Template.hello.foo = function() {
return foo;
}

Template.hello.sum = function() {
a  = 2;
b = 2;
c = (a + b);
return c;
}

One of the most efficient ways is to create template variables via helpers.

Template.hello.helpers({
list: [{'label': 'One'    }, {'label': 'Two'}, {'label': 'Three'}],
sum: function() {
return (2+2);
}
});

Once we have some template variables defined, we can output them in our template. Depending on the kind of variable, we can do this a few ways. Using our example variables above, our modified template could look like this;

<template name="hello">
<h1>{{greeting}}</h1>
<ul>
{{#each list}}
<li>{{label}}</li>
{{/each}}
</ul>

<h3>{{sum}}</h3>
<p>{{foo}}</p>
</template>

Since list is an array of objects, we can use meteor’s {{#each}} to iterate through it and output each item’s properties.

Now you have the basics of meteor.js down. Keep in mind that meteor.js excels at real-time applications. Chat rooms, messaging, anything the could benefit from live data. As web applications start to mature past the already robust features of AJAX/REST driven development, meteor.js could be one of the key players in the next stack of web development.

Month: December 2014

Google Web Toolkit (GWT) using Eclipse