Gaelyk doesn’t support multiple closures in a controller class to automatically expose URLs by convention like Grails does. Instead you have to define your URL routing for each operation separately.

war/WEB-INF/routes.groovy:

get  "/goals",                forward:  "/showGoals.groovy"
get  "/goals/add",            forward:  "/WEB-INF/pages/goal.gtpl"
post "/goals/insert",         forward:  "/insertGoal.groovy"
get  "/goals/delete/@id",     forward:  "/deleteGoal.groovy?id=@id"
get  "/goals/edit/@id",       forward:  "/editGoal.groovy?id=@id"
post "/goals/update",         forward:  "/updateGoal.groovy"

To show all Goals I defined a Groovlet named showGoals.groovy that uses the App Engine datastore low-level API to retrieve them and forward to the view goals.gtpl. In the view you can add a new goal or edit/delete existing goals.

war/WEB-INF/groovy/showGoals.groovy:

import com.google.appengine.api.datastore.Query
import com.google.appengine.api.datastore.PreparedQuery
import static com.google.appengine.api.datastore.FetchOptions.Builder.*

log.info "Getting all goals"

def query = new Query("Goal")
PreparedQuery preparedQuery = datastore.prepare(query)
query.addSort("created", Query.SortDirection.DESCENDING)
def goals = preparedQuery.asList(withDefaults())

request.goals = goals

forward '/WEB-INF/pages/goals.gtpl'

war/WEB-INF/pages/goals.gtpl:

<% include '/WEB-INF/includes/header.gtpl' %>

<h2>Goals</h2>

<a href="/goals/add">Add Goal</a>
<br><br>
<table border="1">
  <thead>
     <tr>
        <th>Name</th>
        <th>Description</th>
        <th>Created</th>
        <th>&nbsp;</th>
     </tr>
  </thead>
  <tbody>
     <% request.goals.each { goal -> %>
        <tr>
           <td>${goal.name}</td>
           <td>${goal.description}</td>
           <td>${goal.created}</td>
           <td><a href="/goals/delete/${goal.key.id}">Delete</a> | <a href="/goals/edit/${goal.key.id}">Edit</a></td>
        </tr>
     <% } %>
  </tbody>
</table>

<% include '/WEB-INF/includes/footer.gtpl' %>

The operations insert and edit share a common view named goal.gtpl. Based on whether the request contains the attribute goal the view will be in insert or edit mode. In case an existing Goal entity was provided the form gets populated with the entity data and is ready to be updated. The Goal to be edited will be retrieved by providing the entity’s ID in the editGoal.groovy Groovlet.

war/WEB-INF/groovy/editGoal.groovy:

import com.google.appengine.api.datastore.KeyFactory
import com.google.appengine.api.datastore.Key

log.info "Editing goal"

def id = Long.parseLong(params.id)
Key key = KeyFactory.createKey("Goal", id)
def goal = datastore.get(key)

request.goal = goal
forward '/WEB-INF/pages/goal.gtpl'

war/WEB-INF/pages/goal.gtpl:

<% include '/WEB-INF/includes/header.gtpl' %>

<%
  def goal = request.getAttribute("goal")
  boolean existingKey = goal?.key
  String action = !existingKey ? 'Add' : 'Update'
%>

<h2>${action} Goal</h2>

<form action="/goals/${!existingKey ? 'insert' : 'update'}" method="POST">
   <table border="0">
      <tbody>
         <tr>
            <td>Name:</td>
            <td><input type="text" name="name" value="${goal?.name ? goal.name : ''}"></td>
         </tr>
         <tr>
            <td>Description:</td>
            <td><input type="text" name="description" value="${goal?.description ? goal.description : ''}"></td>
         </tr>
      </tbody>
      <% if(existingKey) { %>
         <input type="hidden" name="id" value="${goal.key.id}">
      <% } %>
   </table>
   <br>
   <input type="submit" value="${action}">
   <input type="button" value="Cancel" onclick="javascript:document.location.href = '/goals';">
</form>

<% include '/WEB-INF/includes/footer.gtpl' %>

At last we need to implement the Groovlets for persisting the changes to your entity. All of them are quite straight forward to implement. Gaelyk’s abstractions for the datastore work quite nicely.

war/WEB-INF/groovy/insertGoal.groovy:

import com.google.appengine.api.datastore.Entity

log.info "Inserting goal"

def goal = new Entity("Goal")
goal.name = params.name
goal.description = params.description
goal.created = new Date()
goal.save()

redirect '/goals'

war/WEB-INF/groovy/updateGoal.groovy:

import com.google.appengine.api.datastore.KeyFactory
import com.google.appengine.api.datastore.Key

log.info "Updating goal"

def id = Long.parseLong(params.id)
Key key = KeyFactory.createKey("Goal", id)
def goal = datastore.get(key)
goal.name = params.name
goal.description = params.description
goal.save()

redirect '/goals'

war/WEB-INF/groovy/deleteGoal.groovy:

import com.google.appengine.api.datastore.KeyFactory
import com.google.appengine.api.datastore.Key

log.info "Deleting goal"

def id = Long.parseLong(params.id)
Key key = KeyFactory.createKey("Goal", id)
key.delete()

redirect '/goals'

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
   <cron>
      <url>/user/ping</url>
      <description>Keep the app alive by ping every 1 minutes</description>
      <schedule>every 1 minutes</schedule>
   </cron>
</cronentries>

Clearly, App Engine calls for a lightweight application framework until the cold startup issues have been resolved by Google in some sort of form. This puts Grails out of the running as a production-ready framework on App Engine. No company can afford exceptions being thrown on paying customers. This is not an issue solely to Grails. I am sure the startup times for full-fledged Spring applications on App Engine are not extremely better. An alternative for a Groovy-based web framework can be seen in Gaelyk. Gaelyk is not as feature-rich as Grails but will give you the benefit of faster startup times. Implementing non-trivial web applications with Gaeylk can be painful to develop because it’s not as feature-rich as Grails is. I guess in the end there’s always a tradeoff.

More on this topic:

• Grails on Google App Engine – Part 1: A Case Study
• Grails on Google App Engine – Part 2: Project Setup
• Grails on Google App Engine – Part 3: Persistence
• Grails on Google App Engine – Part 4: Third-Party Libraries

Security

Spring Security fits right into the Grails technology stack and it a proven solution for authenticating/authorizing users. This section will only describe the steps necessary to specifically integrate Spring Security with Grails on App Engine. For a detailed configuration description please refer to the Spring Security documentation. I set up my application with version 3.0.3 by dropping in the JAR files into the lib directory. Spring Security in it’s default configuration requires your container to support sessions. This is no problem for App Engine. You have to make sure though that you enable them. The configuration file appengine-web.xml has to have this entry to make it work:

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
   ...
   <sessions-enabled>true</sessions-enabled> 
   ...
</appengine-web-app>

First of all I declared my domain objects User and Role. Please see the Spring Security database schema for more information.

package com.favalike

import com.google.appengine.api.datastore.Key
import javax.jdo.annotations.*

@PersistenceCapable(identityType = IdentityType.APPLICATION, detachable="true")
class User {
   @PrimaryKey
   @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
   Key key

   @Persistent
   String username

   @Persistent
   String password

   @Persistent
   boolean enabled

   @Persistent(defaultFetchGroup = "true")
   List<Role> authorities = new ArrayList<Role>()
}

package com.favalike

import com.google.appengine.api.datastore.Key
import javax.jdo.annotations.*

@PersistenceCapable(identityType = IdentityType.APPLICATION, detachable="true")
class Role {
   @PrimaryKey
   @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
   Key key

   @Persistent
   String authority

   @Persistent
   User user
}

Because Spring Security doesn’t define a JDO UserDetailsService implementation that would be compatible with App Engine you have to write it yourself.

package com.favalike.security

import org.apache.commons.lang.StringUtils
import org.apache.commons.logging.Log
import org.apache.commons.logging.LogFactory
import org.springframework.context.support.MessageSourceAccessor
import org.springframework.dao.DataAccessException
import org.springframework.dao.DataRetrievalFailureException
import org.springframework.security.core.SpringSecurityMessageSource
import org.springframework.security.core.authority.GrantedAuthorityImpl
import org.springframework.security.core.userdetails.User
import org.springframework.security.core.userdetails.UserDetails
import org.springframework.security.core.userdetails.UserDetailsService
import org.springframework.security.core.userdetails.UsernameNotFoundException
import org.springframework.security.authentication.BadCredentialsException

class JdoUserDetailsService implements UserDetailsService {
   static final Log log = LogFactory.getLog(JdoUserDetailsService)
   def userService
   MessageSourceAccessor messages = SpringSecurityMessageSource.getAccessor()

   public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException, DataAccessException {
      if(StringUtils.isBlank(username)) {
         log.error "Username was empty. Authentication failed."
         throw new BadCredentialsException(messages.getMessage("login.username.blank", [] as Object[], "Username may not be empty"), username)
      }

      def user = null

      try {
         user = userService.findUserByUsername(username)
      }
      catch(Exception e) {
         log.error "Problem retrieving user from database", e
         throw new DataRetrievalFailureException(messages.getMessage("login.database.error", [] as Object[], "User could not be retrieved from database. Please try later"))
      }

      if(user == null) {
         log.error "User for username '${username}' not found in database. Authentication failed."
         throw new UsernameNotFoundException(messages.getMessage("JdbcDaoImpl.notFound", [username] as Object[], "Username {0} not found"), username)
      }

      if(log.infoEnabled) {
         log.info "Found user for username '${username}': ${user}"
      }

      def grantedAuthorities = []

      user.authorities.each { role ->
         grantedAuthorities << new GrantedAuthorityImpl(role.authority)
      }

      if(grantedAuthorities.size() == 0) {
         log.error "User needs to have at least one granted authority!"
         throw new UsernameNotFoundException(messages.getMessage("JdbcDaoImpl.noAuthority", [username] as Object[], "User {0} has no GrantedAuthority"), username)
      }

      if(log.infoEnabled) {
         log.info "User found for username '${username}'."
      }

      return new User(user.username, user.password, user.enabled, true, true, true, grantedAuthorities)
   }
}

I was able to put all the Spring wiring for Spring Security in grails-app/conf/spring/resources.groovy. My configuration is pretty much the ordinary security setup you would have to define for every application using Spring Security except that I defined it in Groovy.

beans = {
   // Security
   xmlns security: 'http://www.springframework.org/schema/security'

   jdoUserDetailsService(com.favalike.security.JdoUserDetailsService) {
      userService = ref('userService')
   }

   passwordEncoder(org.springframework.security.authentication.encoding.Md5PasswordEncoder)

   security.'http'('auto-config': true, 'access-denied-page': '/user/index') {
      security.'intercept-url'('pattern': '/user/index*', 'filters': 'none')
      security.'intercept-url'('pattern': '/user/signup', 'filters': 'none')
      security.'intercept-url'('pattern': '/favicon.ico', 'filters': 'none')
      security.'intercept-url'('pattern': '/**/*.html', 'access': 'ROLE_USER')
      security.'intercept-url'('pattern': '/**/*.js', 'access': 'ROLE_USER')
      security.'intercept-url'('pattern': '/**/*.gsp', 'access': 'ROLE_USER')
      security.'intercept-url'('pattern': '/**', 'access': 'ROLE_USER')
      security.'form-login'('authentication-failure-url': '/user/index?login_error=1', 'default-target-url': '/', 'login-page': '/user/index')
      security.'remember-me'('key': '99sdfll74soq')
      security.'logout'('logout-success-url': '/user/index')
   }

   security.'authentication-manager'('alias': 'authenticationManager') {
      security.'authentication-provider'('user-service-ref': 'jdoUserDetailsService') {
         security.'password-encoder'('hash': 'md5')
      }
   }
}

HTTP Calls

App Engine provides you with the URL Fetch API right out of the box. Even though the API does its job it is relatively feature-less. If you need more advanced feature sets like support for cookies you can turn to HttpClient. All you need to do is to download version 4 of the HttpComponents and drop the libraries into your lib directory. HttpClient needs some additional work to make it run on App Engine. It usually works with java.net package which is not allowed on App Engine. This posting shows you a way to work around it.

package com.favalike.http

import org.apache.commons.logging.Log
import org.apache.commons.logging.LogFactory
import org.apache.http.Header
import org.apache.http.HttpEntity
import org.apache.http.client.HttpClient
import org.apache.http.client.methods.HttpGet
import org.apache.http.client.methods.HttpUriRequest
import org.apache.http.conn.ClientConnectionManager
import org.apache.http.impl.client.DefaultHttpClient
import org.apache.http.params.BasicHttpParams
import org.apache.http.params.CoreConnectionPNames
import org.apache.http.params.CoreProtocolPNames
import org.apache.http.params.HttpParams
import org.apache.http.util.EntityUtils

class CommonsHttpRequestExecutor implements HttpRequestExecutor {
   static final Log log = LogFactory.getLog(CommonsHttpRequestExecutor)
   final Integer timeout

   CommonsHttpRequestExecutor(timeout) {
      this.timeout = timeout
   }

   def HttpResponse sendGetRequest(String url) {
      HttpGet httpGet = new HttpGet(url);

      if(log.debugEnabled) {
         log.debug("Sending GET request to URL '${httpget.getURI()}'")
      }

      executeHttpRequest(httpGet);
   }

   def executeHttpRequest(HttpUriRequest httpUriRequest) {
      HttpResponse httpResponse = new HttpResponse()
      HttpClient httpclient = getDefaultHttpClient()

      try {
         def response = httpclient.execute(httpUriRequest)
         populateResponseData(response, httpResponse)
      }
      catch(Exception e) {
         log.error("Error accessing site for url '${httpUriRequest.getURI()}'", e)
         httpResponse.errorMessage = e.message
         httpUriRequest.abort()
      }
      finally {
         httpclient.getConnectionManager().shutdown();
      }

      httpResponse
   }

   def getDefaultHttpClient() {
      ClientConnectionManager clientConnectionManager = new GAEConnectionManager();
      HttpParams params = new BasicHttpParams();
      params.setParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, timeout);
      params.setParameter(CoreProtocolPNames.HTTP_CONTENT_CHARSET, "UTF-8");    
      new DefaultHttpClient(clientConnectionManager, params)
   }

   def populateResponseData(actualResponse, httpResponse) {
      httpResponse.statusCode = actualResponse.statusLine.statusCode
      httpResponse.reasonPhrase = actualResponse.statusLine.reasonPhrase
      httpResponse.statusLine = actualResponse.statusLine.toString()
      HttpEntity entity = actualResponse.getEntity();
      
      if(entity != null) {
         byte[] content = EntityUtils.toByteArray(entity)
         Header header = entity.getContentType() 
         httpResponse.responseBody = new String(content)
      }
   }
}

More on this topic:

• Grails on Google App Engine – Part 1: A Case Study
• Grails on Google App Engine – Part 2: Project Setup
• Grails on Google App Engine – Part 3: Persistence
• Grails on Google App Engine – Part 5: Conclusion

Domain Classes

Grails domain classes have to reside in grails-app/domain and must be placed in a package. Only then the DataNucleus tool will enhance your classes. App Engine introduces its own data types. You definitely want to have a look at the list before you define the data types to your fields. It’s really a hassle to change the data type after you deployed your application to production and want to change the data type. Usually that means that you have to run a data migration script because App Engine might throw an exception on you for existing data. In my application I used the data type com.google.appengine.api.datastore.Key as primary key. The class Key has a String representation that you can use if you want to send it to your client code. This String representation can be converted back to a Key. The class you use for that is com.google.appengine.api.datastore.KeyFactory.

String bookmarkId = KeyFactory.keyToString(bookmark.key)
Key key = KeyFactory.stringToKey(bookmarkId)

You can try to exclude the default domain object fields id and version. However, that doesn’t quite propagate down to App Engine. The DataStore Viewer still shows both fields. I am not sure if there’s a different way around it.

static mapping = {
   id visible: false
   version visible: false
}

Defining relationships between domain objects can be tedious. More than often you run into funny error messages trying to store or retrieve data. You got to read the App Engine manual very closely to make them work. Especially when it comes down to defining many to many and self-referential owned relationship it can get hairy. Often times I had to fall back to just reference the Key of a different domain class to create a relationship.

Service Classes

The App Engine plugin automatically configures and provides you with Spring’s JdoTemplate that can be injected into your Grails services. Transaction boundaries can be set by wrapping your database interactions into a transactionTemplate. The JdoTemplate is easy to use and shouldn’t be new to you if you used one of Spring’s template implementations before like the JdbcTemplate. In some cases I had to fall back to the JDO low-level API because the JdoTemplate doesn’t provide the functionality. For my needs I created a super class that injects the JdoTemplate and the transactionTemplate.

class JdoService {
   def jdoTemplate
   def transactionTemplate
}

By default the JDO persistence configuration (jdoconfig.xml) created by the App Engine plugin auto-creates transactions. If you want to have full control over your transactions use the transactionTemplate. When you want to operate on more than one domain object within a transaction you have to set the property datanucleus.appengine.autoCreateDatastoreTxns to false.

<?xml version="1.0" encoding="utf-8"?>
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">

    <persistence-manager-factory name="transactions-optional">
        ...
        <property name="datanucleus.appengine.autoCreateDatastoreTxns" value="false"/>
    </persistence-manager-factory>
</jdoconfig>

Using the JdoTemplate doesn’t require you to close your connection. This is being handled by Spring. This is an example on how I used it:

def findAllByUser() {
   def bookmarks = []

   transactionTemplate.execute( { status ->
      def user = getLoggedInUser()
      bookmarks = jdoTemplate.find(Bookmark, "userKey == userKeyParam", "com.google.appengine.api.datastore.Key userKeyParam", [user.key] as Object[], "created asc")
   } as TransactionCallback)

   bookmarks
}

Despite the benefits of JdoTemplate you sometimes have to leverage the low-level API. However, you don’t have to create a class to retrieve the PersistenceManagerFactory. You can easily get it from the JdoTemplate. Make sure you close your resources after you used them. I wrote a little helper class to does that. One of the reasons I had to use the low-level API was to implement pagination. I chose to go down the naive, classic path of counting all records of a specific domain object and then retrieve the a list of these objects for the page we want to display. Using the range operator has implications for performance: the datastore must retrieve and then discard all results prior to the starting offset. For example, a query with a range of 5, 10 fetches 10 results from the datastore, then discards the first 5 and returns the remaining 5 to the application. I don’t expect users to have thousands and thousands of bookmarks in one folder so this would be a minor issue. Furthermore, I wanted to get up and running as soon as possible. Alternatively, this posting describes a performant but harder to implement solution.

def findAllByUserInRange(offset, max) {
   def bookmarks = []
   def total

   transactionTemplate.execute( { status ->
      def user = getLoggedInUser()
      Query query

      try {
         final filter = "userKey == userKeyParam"
         final parameters = "com.google.appengine.api.datastore.Key userKeyParam" 
         query = jdoTemplate.getPersistenceManagerFactory().getPersistenceManager().newQuery(Bookmark)
         query.setFilter(filter)
         query.declareParameters(parameters);
         query.setResult("count(this)")
         total = query.execute(user.key)
         query = jdoTemplate.getPersistenceManagerFactory().getPersistenceManager().newQuery(Bookmark)
         query.setFilter(filter)
         query.declareParameters(parameters);
         query.setOrdering("created asc")
         query.setRange(offset, offset + max)
         bookmarks = query.execute(user.key)
      }
      finally {
         JdoUtil.closeAll(query)
      }
   } as TransactionCallback)

   new Page(offset, max, total, bookmarks)
}

Indexes

The App Engine datastore maintains an index for every query an application intends to make. As the application makes changes to datastore entities, the datastore updates the indexes with the correct results. When the application executes a query, the datastore fetches the results directly from the corresponding index. As this might hold true for your development machine this isn’t necessarily true when you deploy your application to App Engine. Often times App Engine didn’t indicate that I have a missing index. You either have to analyze your queries very closely and add the indexes manually in grails-app/conf/datastore-indexes.xml or you’ll find yourself seeing exceptions. These exception can be fixed easily. However, you have to redeploy your application. It might take App Engine a while (sometimes 30 minutes or longer) to build the indexes once you have them defined. Indexes that are in the process of being built cannot serve the query causing an exception. This makes it impossible to deploy a new index without problems for your users. At the moment there’s no way to delete indexes over the administration console.

More on this topic:

• Grails on Google App Engine – Part 1: A Case Study
• Grails on Google App Engine – Part 2: Project Setup
• Grails on Google App Engine – Part 4: Third-Party Libraries
• Grails on Google App Engine – Part 5: Conclusion

log4j = {
   appenders {
      console name:'stdout', layout:pattern(conversionPattern: '%d{dd MMM yyyy HH:mm:ss,SSS} [%t] %-5p %c{2} - %m%n')
   }

   debug  'grails.app', 'com.favalike'
   ...
}

The plugin still has a bug related to i18n. In case you’re using one of the messages.properties files to store internalized texts that would leave these files empty after building the WAR file. I could still make it work by applying the workaround described in the JIRA ticket. You got to change your Bootstrap.groovy as follows and build your WAR file for production environment: grails -Dgrails.env=production app-engine package.

import grails.util.Environment

class BootStrap {
   def messageSource

   def init = { servletContext ->
      if(Environment.getCurrent() == Environment.PRODUCTION) {
         messageSource.basenames = ['WEB-INF/grails-app/i18n/messages']
         messageSource.clearCache()
      }
   }

   def destroy = {
   }
} 

To improve performance from the get go I made sure I had precompilation enabled. Furthermore, static files can get served by dedicated servers and caches. Both settings are made in appengine-web.xml.

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
   ...
   <precompilation-enabled>true</precompilation-enabled>
   <static-files>
      <include path="/favicon.ico" />
      <include path="/css/**.css" />
      <include path="/images/**.*" />
      <include path="/js/**.js" expiration="1d" />    
   </static-files>
</appengine-web-app>

More on this topic:

• Grails on Google App Engine – Part 1: A Case Study
• Grails on Google App Engine – Part 3: Persistence
• Grails on Google App Engine – Part 4: Third-Party Libraries
• Grails on Google App Engine – Part 5: Conclusion

To limit the amount of work I’d have to put into this experiment I chose to implement a online bookmark manager with limited functionality. The features I wanted to cover should also take advantage of some of the services provided by App Engine. My plan was to use the Mail service and the URL Fetch API to get a feel on how easy it is to use them.

• User registration and confirmation via email
• User authenication
• Management of bookmarks in folders per user
• Tagging of bookmarks
• Marking bookmarks as favorites
• Automatic retrieval of URL meta data
• Export of bookmarks as XML and HTML

The final result became Favalike which uses Grails 1.3.1 and the App Engine plugin 0.8.10. The following postings will describe my experience and the challenges I had to face in detail.

More on this topic:

• Grails on Google App Engine – Part 2: Project Setup
• Grails on Google App Engine – Part 3: Persistence
• Grails on Google App Engine – Part 4: Third-Party Libraries
• Grails on Google App Engine – Part 5: Conclusion

Create the directory $CATALINA_HOME/webapps/solr/WEB-INF/classes and add the file log4j.properties. The file should hold your Log4J configuration. Here’s an example using a rolling log file:

log4j.rootLogger=ERROR, logfile

log4j.appender.logfile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.logfile.File=${catalina.home}/logs/solr.log

log4j.appender.logfile.DatePattern='.'yyyy-MM-dd
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c{3}] - [%t] - %X{ip}: %m%n

Alternatively, you can prepare your Solr web application WAR file to reflect the steps mentioned above. The Solr logging page (http://<host>:<port>/solr/admin/logging) that comes with the web app will not reflect these changes. It only works for JDK logging that we just configured not to be used anymore. The Tomcat instance has to be restarted to reflect the changes.

If your application makes AJAX calls to your server-side components jQuery’s AJAX implementation comes in handy. Usually you want to handle at least the successful and erroneous response of that call. Today’s web applications (like Gmail) based on a lot of AJAX calls display a “busy/loading” indicator like a spinner or some text.

JavaScript supports the Factory pattern (see the book “Pro JavaScript Design Patterns”) which lets you create an implementation with the new keyword. The nice thing about it is that you can even create multiple implementations that handle your HTTP calls differently. The methods are being added over the the class’s prototype object. Below you’ll find an implementation for making AJAX calls using jQuery. For each GET or POST call you pass in a callback variable. The callback variable defines how to handle the response.

ajax.js:

var AjaxHttpSender = function() {};

AjaxHttpSender.prototype.sendGet = function(url, callback) {
   $.ajax({
      url: url,
      type: 'GET',
      beforeSend: function() {
         onStartAjaxRequest();
      },
      error: function(XMLHttpRequest, textStatus, errorThrown) {
         callback.failure(XMLHttpRequest, textStatus, errorThrown);
      },
      success: function(data, textStatus) {
         callback.success(data, textStatus);
      },
      complete: function (XMLHttpRequest, textStatus) {
         onEndAjaxRequest();
      }
   });
}

AjaxHttpSender.prototype.sendPost = function(url, data, callback) {
   $.ajax({
      url: url,
      type: 'POST',
      data: data,
      beforeSend: function() {
         onStartAjaxRequest();
      },
      error: function(XMLHttpRequest, textStatus, errorThrown) { 
         callback.failure(XMLHttpRequest, textStatus, errorThrown);
      },
      success: function(data, textStatus) {
         callback.success(data, textStatus);
      },
      complete: function (XMLHttpRequest, textStatus) {
         onEndAjaxRequest();
      }
   });
}

function onStartAjaxRequest() {
    // e.g. show spinner
}

function onEndAjaxRequest() {
    // e.g. hide spinner
}

Usage Example:

<script type="text/javascript" src="js/jquery-1.3.2.min.js"></script>
<script type="text/javascript" src="js/ajax.js"></script>
<script type="text/javascript">
   var callback = {
      success: function(data, textStatus) {
         $('#content').html(data);
      },
      failure: function(XMLHttpRequest, textStatus, errorThrown) {
         alert('Error making AJAX call: ' + XMLHttpRequest.statusText + ' (' + XMLHttpRequest.status + ')');
      }
   }

   function makeAjaxCall() {
      var ajaxHttpSender = new AjaxHttpSender();
      ajaxHttpSender.sendGet(url, callback);
   }
</script>

The park is perfect for hiking up the mountains to catch breathtaking views of the area. There are multiple paths you can follow. From beginner to expert you should find a trail that suits you well. The park has much more to offer than you can cover in one day. Someday I’ll drive the whole 105 miles of the Skyline Drive. A camping trip is already in planning.

Knowing that we just have three days to explore the city we tried to pack as much sightseeing into our day as we could. A must is seeing the Golden Gate Bridge. Don’t forget to bring a sweater. It’s always kind of chilly. In this city weather can change fast. We decided to take the boat tour in the bay which also let us see Alcatraz. We tried to avoid setting a foot on the island. There are masses of tourists and I don’t think you actually miss something. While being in the bay area we checked with Giradelli. They give out free samples in their store. Even though the samples are good I still think European chocolate tastes better. Don’t miss out on Lombard Street. Probably the funniest street I’ve ever seen.

Did I already tell you that I love San Francisco? This city really has flair. From great panorama views from up the hill to laid back people. This city is adorable. Personality is everywhere. People keep their architecture and culture intact and maintain it well. Apart from the hiking to get from point a to b it takes time to get around. After a while we actually decided to always take the taxi. Cable Cars are definitely made to entertain tourists but are a rip off. You pay the same price for a ride with a taxi. Because we got so many recommendations from friends for good restaurants and bars we wanted to visit taxis are the way to go.

We got a good impression of San Francisco within three days. If prices for living wouldn’t be that high we would totally consider living there. Sarah and I will go there again. Next up: Making a tour to the wineries and exploring the surrounding area.