Work on the new module repository for Play is progressing nicely, but a very subtle bug was introduced into the Build.scala file. As a result, artifacts from the first repository were not being found. Can you spot the difference here? The first code snippet is correct, and the second is faulty.

val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings (
    resolvers += Resolver.url("Objectify Play Repository", url("http://schaloner.github.com/releases/"))(Resolver.ivyStylePatterns),
    resolvers += Resolver.url("Scala Tools", url("http://scala-tools.org/repo-releases/"))(Resolver.ivyStylePatterns)
  )

val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings {
    resolvers += Resolver.url("Objectify Play Repository", url("http://schaloner.github.com/releases/"))(Resolver.ivyStylePatterns)
    resolvers += Resolver.url("Scala Tools", url("http://scala-tools.org/repo-releases/"))(Resolver.ivyStylePatterns)
  }

The problem was caused by using curly brackets instead of parentheses. Note also that when using curly brackets, you can’t put a comma after the first resolver. However, the file still compiles without a problem. Very subtle, very annoying!

So, the correct form is the first snippet above – here with bold to emphasise the key points.

val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings (
    resolvers += Resolver.url("Objectify Play Repository", url("http://schaloner.github.com/releases/"))(Resolver.ivyStylePatterns),
    resolvers += Resolver.url("Scala Tools", url("http://scala-tools.org/repo-releases/"))(Resolver.ivyStylePatterns)
  )

There seems to be some confusion regarding Play 2 modules and plugins. I imagine this is because the two are often synonymous. In Play (both versions – 1 and 2) there are distinct differences. In this post, I’m going to look at what a plugin is, how to implement one in Java and Scala, and how to import plugins from modules.

Plugins

A Play 2 plugin is a class that extends the Java class play.Plugin or has the Scala trait play.api.Plugin. This class may be something you have written in your own application, or it may be a plugin from a module.

Writing a plugin in Java

Create new class, and have it extend play.Plugin. There are three methods available to override – onStart(), onStop() and enabled(). You can also add a constructor that takes a play.Application argument.

To have some functionality occur when the application starts, override onStart(). To have functionality occur when the application stops, override onStop(). It’s that simple! Here’s an example implementation which doesn’t override enabled().

package be.objectify.example;

import play.Application;
import play.Configuration;
import play.Logger;
import play.Plugin;

/**
 * An example Play 2 plugin written in Java.
 */
public class MyExamplePlugin extends Plugin
{
    private final Application application;

    public MyExamplePlugin(Application application)
    {
        this.application = application;
    }

    @Override
    public void onStart()
    {
        Configuration configuration = application.configuration();
        // you can now access the application.conf settings, including any custom ones you have added
        Logger.info("MyExamplePlugin has started");
    }

    @Override
    public void onStop()
    {
        // you may want to tidy up resources here
        Logger.info("MyExamplePlugin has stopped");
    }
}

Writing a plugin in Scala

Create a new Scala class, and have it extends play.api.Plugin. Just as in the Java version, there are onStart(), onStop() and enabled() methods along with an play.api.Application constructor argument. Here’s the Scala implementation:

package be.objectify.example

import play.api.{Logger, Application, Plugin}

/**
 * An example Play 2 plugin written in Scala.
 */
class MyExamplePlugin(application: Application) extends Plugin
{
  override def onStart()
  {
    val configuration = application.configuration;
    // you can now access the application.conf settings, including any custom ones you have added
    Logger.info("MyExamplePlugin has started");
  }

  override def onStop()
  {
    // you may want to tidy up resources here
    Logger.info("MyExamplePlugin has stopped");
  }
}

Hooking a plugin into your application

Regardless of the implementation language, plugins are invoked directly by Play once you have added them to the conf/play.plugins file. This file isn’t created when you start a new application, so you need to add it yourself. The syntax is <priority>:<classname>. For example, to add the example plugin to your project, you would use

10000:be.objectify.example.MyExamplePlugin

The class name is that of your plugin. The priority determines the order in which plugins start up, and just needs to be a number that is larger or smaller than that of another plugin. If you have several plugins, you can explicitly order them:

5000:be.objectify.example.MyExamplePlugin
10000:be.objectify.example.MyOtherExamplePlugin

Modules

A module can be thought of as a reusable application that you can include in your own app. It’s analogous to a third-party library that adds specific functionality. A module can contain plugins, which you can hook into your app using the conf/play.plugins file.

For example, if you’re using Deadbolt 2 you would need to add the following to your play.plugins file:

10000:be.objectify.deadbolt.DeadboltPlugin

A list of Play 2 modules can be found on the Play 2 GitHub wiki.

You can read more on creating modules for Play 2 here and here.

This post is coming quite a way after the fact, but I just read this tweet from Pamela Fox and it reminded me that I’ve been meaning to mention this for ages.

Back in November at Devoxx here in Belgium, one of the major themes was women in IT*. I asked my female colleague (who is, by the way, an exceptional developer but I’m not going to name her because I haven’t asked permission!) if she was attending any of the talks. She said no, and then went on to explain her viewpoint.

I’m paraphrasing from memory here, but the gist of the argument was “software developers are already a minority, and I don’t like the idea of creating an unnecessary sub-minority“.

This surprised me a lot. From one point of view, I can see where she’s coming from – as software developers, we’re already regarded (to a lesser or greater degree) as a bit strange**, and we need to hang together if we’re going to avoid being hung separately. From another viewpoint, however, it ignores the marginalisation of women by men who are in the same industry. I was going to use the word victimisation, but I’ve never witnessed it personally (and you can be damn sure it wouldn’t happen twice in my presence, regardless of the gender of the victim) – maybe a commenter can bring me up to speed on this?

I’ve been lucky enough through my career to work with some exceptional developers who happened to be female. In fact, I’ve never worked with a female developer who was any less than excellent – but there’s probably a very good reason for that. Since the overwhelming majority of developers are men, it follows that the majority of bad developers are also men. I’m pretty crappy with statistics, and they can famously be made to say anything, but it seems to me that the women who punch through the marginalisation barrier do so based on skill, and thus skew the figures even more.

Right now, I’m feeling very concious about what I’m writing, with the usual thoughts of sounding patronising and, frankly, feeling like the kind of dipshit who dumps his brain into his blog only to get it run through a blender. C’est le vie.

* The chivalrous part of me wasn’t sure to use women, ladies, girls or females. Since “Men in IT” is what I would write if this were about men, the feminine noun seems to me to be the correct one.
** Strange, in this case, defining a group of people who will have vitriolic arguments over the formatting of JavaScript, for example.

When I attended the BeJUG session on the Play! Framework a few weeks ago, I was glad (but not especially surprised) to see how popular the session was. It’s been a busy few weeks since then, but in the meantime I’ve been thinking it’s time for a Belgian User Group for Play!.

I’ve already created a Google Group for it at https://groups.google.com/forum/#!forum/play-be and sent out invitations to people that have expressed an interest. Initially, I plan to start it small and get a meet-up organised. Belgium is small enough that (in theory) no-one should have to travel too far.*

This is the first time I’ve ever tried something like this, so I’ll be asking various other user group founders for tips and hints to make the process as painless and smooth as possible. I’ll be blogging on the development of the group as more things happen, and will include any and all good advice I receive for anyone else who’s thinking of doing this.

Against some of the perceived issues that have arisen between versions 1 and 2, an explicit goal of this user group is to include Play 1, Play 2, Java and Scala – the key is Play, and not a subset of it.

* Of course, in Belgium, distance is measured in traffic density and not kilometers

If you’ve read any other entries on this blog, you’ll know that I’m an advocate of the Play! Framework.

As of today, this has changed.

My client is currently in the process of migrating their services to a federated collection of web services. Business metrics are required, and so we needed to look at a logging service. We discussed various options, and my proposal was accepted. We have a few well-defined fields, and service-specific data is logged as a JSON document. The discussion lasted about 25 minutes or so.

I went back to my desk, and wrote the code – a RESTful service, an asynchronous client using Akka, and a front-end in 15 minutes – using Play 2.

Let me spell that out, in case you missed the figures. Implementing the entire solution took 3/5s the length of time of the meeting.

Can you imagine doing that with another web framework, especially in the Java space? Play is, by definition at this point, an embarrassment – it can, should and will make other frameworks embarrassed of what they can offer.

I’m no longer an advocate of the Play! Framework. I’m an unequivocal advocate of it.

Edit: I’ve changed ashamed to embarrassed – ashamed was the wrong word to use, and gave negative connotations.

I’ve just prepared a course on jQuery to give to my colleagues, and one of the sections covers jQuery’s AJAX features. To demonstrate these, I wrote a quick web app using Play 2. Since there have been a few questions asked in various places on how this works, I’m going to break it down here with some simple examples of the main $.ajax() method, plus the shorthand methods that simplify its use.

$.ajax()

jQuery’s $.ajax() method is part of the low-level interface, and can be configured to provide all your AJAX needs. For this example, we’re going to do a simple GET that will result in a 200 response from the server, along with a text message.

The JavaScript:

$.ajax(ajaxParameters({
      url: '/ajax',
      success: function(data, textStatus, jqXHR) {
        window.alert(data);
      },
      error: function(jqXHR, textStatus, errorThrown) {
        window.alert(textStatus);
      }
    }));

Note the URL – this results in a call to http://localhost:9000/ajax, and so must appear in the routes file:

GET     /ajax                       controllers.Application.ajax()

The server-side implementation is about as simple as it gets:

public static Result ajax()
{
    return ok("Here's my server-side data");
}

Responding to errors

Take a look at the JavaScript again – you will see there are handlers declared for success and error conditions. What’s the difference? A 200 response will trigger the success handler, and other codes trigger the error handler. Let’s tweak the code to show this working.

The JavaScript. The only thing that has changed here is the URL – it now points to a URL that is guaranteed to return a non-200 response.

$.ajax(ajaxParameters({
      url: '/ajaxWithError',
      success: function(data, textStatus, jqXHR) {
        window.alert(data);
      },
      error: function(jqXHR, textStatus, errorThrown) {
        window.alert(textStatus);
      }
    }));

The route:

GET     /ajaxWithError              controllers.Application.ajaxWithError()

And the server-side implementation:

public static Result ajaxWithError()
{
    return badRequest("Somehow, somewhere, you screwed up");
}

And that’s it – you’re now handling success and error conditions.

Shorthand methods

jQuery usefully provides shorthand methods that simplify usage of $.ajax(), and in some cases provide additional functionality such as parsing repsonse data into JSON objects, or loading content into elements.

$.get()

$.get() is, unsurprisingly, for issuing asynchronous GETs to the server. You can provide parameters, and give a single function that will be executed if the call is successful.

The JavaScript:

$.get('/get',
      {'foo': 'bar'},
      function(data) {
          window.alert(data);
      });

The route – note this doesn’t specify a method parameter!

GET     /get                        controllers.Application.get()

The server-side implementation:

public static Result get()
{
    Map queryParameters = request().queryString();
    return ok(String.format("Here's my server-side data using $.get(), and you sent me [%s]",
                            queryParameters.get("foo")[0]));
}

Handling errors

In the real world, you will receive errors sometimes and the above JavaScript doesn’t handle this. The key is to use jQuery’s event-handling features instead of providing callbacks. In this example, any success, error and completion events fired by $.get() are handled.

$.get('/getWithError')
      .success(function(data) {
        window.alert('Success: ' + data);
      })
      .error(function(data) {
        window.alert('Error: ' + data.responseText);
      })
      .complete(function(data) {
        window.alert('The call is now complete');
      });

The route:

GET     /getWithError               controllers.Application.getWithError()

The server-side implementation:

public static Result getWithError()
{
    return badRequest("Something went very, very wrong");
}

$.post()

So far, so good, but what if you want to POST data to the server? You can use $.post() for this. Interestingly, there are no shorthand methods for DELETE, PUT, etc – you have to use the $.ajax() method for these.

The semantics are the same as for $.get(), so I’m not going to provide an event-driven here. This is using a regular callback.

The JavaScript:

$.post('/post',
      {'foo':'bar'},
      function(data) {
          window.alert(data);
      });

The route – note the POST HTTP method is used.

POST    /post                       controllers.Application.post()

And the server-side code:

public static Result post()
{
    Map parameters = request().body().asFormUrlEncoded();
    String message = parameters.get("foo")[0];

    return ok(message);
}

$.getJSON()

$.getJSON() loads JSON-encoded data from the server using a GET HTTP request (to steal a line from the jQuery docs). This means the data returned can be treated immediately as a JSON object without the need to process it further.

The JavaScript:

$.getJSON('/getJson',
          function(data) {
              // data is a JSON list, so we can iterate over it
              $.each(data, function(key, val) {
                  window.alert(key + ':' + val);
          });
       });

The route:

GET     /getJson                    controllers.Application.getJson()

Server-side code:

public static Result getJson()
{
    List data = Arrays.asList("foo", "bar");
    return ok(Json.toJson(data));
}

$.getScript()

$.getScript() loads a script from the server using a HTTP GET, and then executes it in the global context.

The JavaScript:

$.getScript('/getScript');

The route:

GET     /getScript                  controllers.Application.getScript()

Server-side code:

public static Result getScript()
{
    return ok("window.alert('hello');");
}

Handling events

This example couldn’t be simpler. It could, however, be slightly more complex. The events generated by $.getScript() are slightly different to the success, error, etc events of the other methods. For $.getScript(), there are done and fail events. For success, you have to use a callback.

$.getScript('/getScriptWithError',
            function() {
                window.alert('This is the success callback');
            })
            .done(function(script, textStatus) {
                window.alert('Done: ' + textStatus);
            })
            .fail(function(jqxhr, settings, exception) {
                window.alert('Fail: ' + exception);
            });

The route:

GET     /getScriptWithError         controllers.Application.getScriptWithError()

The server-side implementation. Note it’s returning a 200 response but with broken JavaScript.

public static Result getScriptWithError()
{
    return ok("this is not a valid script!");
}

.load

Last but not least is .load(). Note this isn’t $.load(), but rather $(a selector).load() as its purpose is to retrieve HTML from the server and place it into the matched element.

The JavaScript:

$('#loadContainer').load('/load');

The route:

GET     /load                       controllers.Application.load()

The server-side implementation:

public static Result load()
{
    return ok(snippet.render());
}

The template:

<div id="aTable">
    <table>
        <tr>
            <td>Foo</td>
            <td>Bar</td>
        </tr>
        <tr>
            <td>Hurdy</td>
            <td>Gurdy</td>
        </tr>
    </table>
</div>
<div id="aList">
    <ul>
        <li>Foo</li>
        <li>Bar</li>
    </ul>
</div>

Loading fragments

.load() can take a second parameter within the URL string, separated by a space. This parameter is a selector – if present, jQuery will extract the selected element from the HTML and insert only that into the target.

$('#loadFragmentContainer').load('/load #aList');

Note there is no change to the route, the server-side code or the template here – this is purely a client-side operation.

That’s all, folks

jQuery simplifies making AJAX calls, and Play simplifies receiving and responding to those calls. A perfect match!

An example implemtation of all these features is available here: jquery-ajax

Now you’ve doubtless followed my earlier guides on writing modules for Play 2, I imagine you’re keen to show your coding chops to the world. The problem is – and this is quite a big one, I’m afraid – there is no place to publish your modules to. When I first starting writing Play modules, the repository was already set-up and ready to go – however, it used a custom format (state of the art download-and-unzip). This changed to some degree with Play 1.2, but I have to say I’m not a fan of that dependency management mechanism; I’m just too damn old to learn these shiny new things.

With Play 2, things swung around again and the dependency mechanism is compliant with Maven and Ivy. I can hear enterprises up and down the planet rejoicing.

However, this still doesn’t help you achieve your well-deserved glory and fame, unless you happen to host your own Maven/Ivy repo or feel like hacking the auto-generated artifact models that Play generates. Help is hand, until Play 2 modules have an official release mechanism, using GitHub’s Pages feature. Very simply, we’ll use Play’s publish-local task to generate all the files we need in the correct directory structure, and then copy that structure as-is directly into GitHub pages. A publish in this manner can be done in less than a minute, after you’ve done the initial set-up in GitHub.

Creating the repository in GitHub

If your GitHub user name is, for example, foo, then creating a repository called foo.github.com hooks you into Pages – what you commit here will be available at http://foo.github.com. There’s no GitHubby goodness when it comes to displaying files here – what you commit is what’s available in its native form. Commit a HTML file (let’s call it bar.html), and point your browser at http://foo.github.com/bar.html and you’ll see the rendered HTML – not the source of it. This makes it ideal for exposing files that you want represented in their raw form – say, the jar file containing your Play 2 module.

So, go ahead and create a .github.com repository and clone it to your workspace, and cd into it. In here, you can replicate (kind of – see later) a meven repository.

To keep things nice, the first directory you should create is releases. If you also want to add a snapshot directory, do it at this level.

Note: When you first create the repository in GitHub, it can take up to 10 minutes for it to become available. If you haven’t changed your email preferences, you should receive a notification when it is ready. This doesn’t stop you committing to the repository in the meantime.

Publish the files locally

Let’s assume your module name is hurdy as the artifact name. Your Build.scala looks like this:

import sbt._
import Keys._
import PlayProject._

object ApplicationBuild extends Build {

    val appName         = "hurdy"
    val appVersion      = "1.0"

    val appDependencies = Seq(
    )

    val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings(
    )
}

(The mainLang value may be something else, depending on your primary language).

In the root of your module, start up Play and publish it locally:

steve@hex:/tmp/hurdy$ play
[info] Loading project definition from /tmp/hurdy/project
[info] Set current project to hurdy (in build file:/tmp/hurdy/)
       _            _
 _ __ | | __ _ _  _| |
| '_ \| |/ _' | || |_|
|  __/|_|\____|\__ (_)
|_|            |__/ 

play! 2.0, http://www.playframework.org

> Type "help play" or "license" for more information.
> Type "exit" or use Ctrl+D to leave this console.

[hurdy] $ clean
[success] Total time: 0 s, completed Apr 21, 2012 9:49:00 AM
[hurdy] $ compile
[info] Updating {file:/tmp/hurdy/}hurdy...
[info] Done updating.
[info] Compiling 4 Scala sources and 2 Java sources to /tmp/hurdy/target/scala-2.9.1/classes...
[success] Total time: 7 s, completed Apr 21, 2012 9:49:08 AM
[hurdy] $ publish-local
[info] Packaging /tmp/hurdy/target/scala-2.9.1/hurdy_2.9.1-1.0-SNAPSHOT-sources.jar ...
[info] Done packaging.
[info] Wrote /tmp/hurdy/target/scala-2.9.1/hurdy_2.9.1-1.0-SNAPSHOT.pom
[info] :: delivering :: hurdy#hurdy_2.9.1;1.0-SNAPSHOT :: 1.0-SNAPSHOT :: release :: Sat Apr 21 09:49:12 CEST 2012
[info] 	delivering ivy file to /tmp/hurdy/target/scala-2.9.1/ivy-1.0-SNAPSHOT.xml
[info] Generating API documentation for main sources...
[info] Packaging /tmp/hurdy/target/scala-2.9.1/hurdy_2.9.1-1.0-SNAPSHOT.jar ...
[info] Done packaging.
model contains 23 documentable templates
[info] API documentation generation successful.
[info] Packaging /tmp/hurdy/target/scala-2.9.1/hurdy_2.9.1-1.0-SNAPSHOT-javadoc.jar ...
[info] Done packaging.
[info] 	published hurdy_2.9.1 to /home/steve/development/play/play-2.0/framework/../repository/local/hurdy/hurdy_2.9.1/1.0-SNAPSHOT/poms/hurdy_2.9.1.pom
[info] 	published hurdy_2.9.1 to /home/steve/development/play/play-2.0/framework/../repository/local/hurdy/hurdy_2.9.1/1.0-SNAPSHOT/jars/hurdy_2.9.1.jar
[info] 	published hurdy_2.9.1 to /home/steve/development/play/play-2.0/framework/../repository/local/hurdy/hurdy_2.9.1/1.0-SNAPSHOT/srcs/hurdy_2.9.1-sources.jar
[info] 	published hurdy_2.9.1 to /home/steve/development/play/play-2.0/framework/../repository/local/hurdy/hurdy_2.9.1/1.0-SNAPSHOT/docs/hurdy_2.9.1-javadoc.jar
[info] 	published ivy to /home/steve/development/play/play-2.0/framework/../repository/local/hurdy/hurdy_2.9.1/1.0-SNAPSHOT/ivys/ivy.xml
[success] Total time: 3 s, completed Apr 21, 2012 9:49:15 AM

Move the published files into GitHub

The files have been published to ${PLAY_HOME}/repository/local, and are contained in the hurdy directory. Move this entire directory to your new git repository

cp -rv ${PLAY_HOME}/repository/local/hurdy <your username>.github.com/releases

Change directory to .github.com, and add all the files to the git repository, commit and push them.

steve@hex:/tmp/schaloner.github.com$ git add .
steve@hex:/tmp/schaloner.github.com$ git commit -m "Added release 1.0 to repository"
steve@hex:/tmp/schaloner.github.com$ git push -u origin master

Use the dependency

Create a new project (or open up an old one), and add the dependency and its location.

object ApplicationBuild extends Build {

    val appName         = "my-cool-project"
    val appVersion      = "2.1"

    val appDependencies = Seq(
      "hurdy" %% "hurdy" % "1.0"
    )

    val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings(
      resolvers += Resolver.url("My GitHub Play Repository", url("http://<your username>.github.com/releases/"))(Resolver.ivyStylePatterns)
    )
}

Note: Play has published the files in an Ivy style pattern, so this needs to be specified in your Build.scala

Start Play in your application root, and run the “dependencies” task. If all goes well – and I’m sure you’ll let me know if it doesn’t – your module will be pulled from GitHub and made available to your application.

Specifiying an organisation

Because there’s no organisation specified in Build.scala, the organisation (repository/local/hurdy/hurdy_2.9.1) is taken to be the same as the module name. If you want an organisation, add it in the main definition:

val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings(
      organization := "com.example"
    )

Now, when you publish locally the files will be placed in repository/local/com.example/hurdy_2.9.1. In this case, it’s the com.example directory that should copied from the local repository to your GitHub repo. The Build.scala of any application using your dependency will be similarly different:

val appDependencies = Seq(
      "com.example" %% "hurdy" % "1.0"
    )

Real-world proof this works

Deadbolt 2 is currently available using this mechanism, using http://schaloner.github.com as the repository. Here, there are release and snapshot versions so the Build scala of the sample applications looks like this:

import sbt._
import Keys._
import PlayProject._

object ApplicationBuild extends Build {

    val appName         = "deadbolt-usage"
    val appVersion      = "1.1.3-SNAPSHOT"

    val appDependencies = Seq(
      "be.objectify" %% "deadbolt-2" % "1.1.3-SNAPSHOT"
    )

    val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings(
      // Change this to point to your local play repository
      resolvers += Resolver.url("Objectify Play Repository", url("http://schaloner.github.com/releases/"))(Resolver.ivyStylePatterns),
      resolvers += Resolver.url("Objectify Play Repository", url("http://schaloner.github.com/snapshots/"))(Resolver.ivyStylePatterns)
    )
}

If I change the required version from 1.1.3-SNAPSHOT (which is in the snapshots/ directory) to 1.1.3 (which will be in the releases/ directory), the dependency will be resolved correctly.

Ever read Freakonomics? There’s a great chapter on how internet-accessible information drove down insurance premiums massively. The same story can be found in many places – but some companies are apparently completely oblivious to this.

Which is the specific company that triggered this blog post? Disney – Disneyland Paris, to be exact.

On visiting their site, I immediately got redirected to the Belgian version of their website. While my level of Dutch is good enough to deal with this, I do prefer English just for speed of reading so I switched to the UK website. I looked up 5 nights in a specific hotel, 2 adults, 1 five-year-old child, starting August 1st. The resulting price – £1338. Expensive, but about what you would expect from Disney. For comparison, the currency converter at OANDA converts this at today’s rate to €1620.70.

Now, having lived in Belgium for some time, and being acutely aware of how expensive it is, I decided to check out the same deal from the Belgian website. Same people, same date, same duration. The result this time? A jaw-dropping €2306. Since this doesn’t include transport, it would be cheaper for me to drive to the UK, turn around, drive to Paris and have the holiday than just drive 3 hours south and have the same exact holiday. What would Al Gore say about this carbon impact?

This goes completely against the concept that people won’t pay 10 for something when information is freely and easily available that indicates they should be paying 5. It does take into account the inherent laziness of some people, and the fact that some people are unaware of this information. For people who are aware of this info, and are willing to do something about it (i.e. me) it’s a complete insult. It’s also a great incentive to not go to Disney.

Remember, the democratization of information the web has brought doesn’t mean anything if you don’t vote! In the meantime, let’s call this a fail for Disney.

Back in November, I spoke to Nicolas Leroux of the Play framework about creating a module repository. He agreed it would be a good idea, but lack of time has prevented me from starting this. Following the stormy events of last week in the Play Google Group, I’ve decided to prioritise it. A working prototype should be available in a couple of weeks.

The overview:
1. It’s open source
Obviously

2. It’s written in Play 2
Just to piss off the nay-sayers

3. Module creation
At the moment, to get a module into the module repository you have to get authorisation from a member of the Play team. I want to have a repo where you can upload any module, as long as it conforms to certain minimum requirements. These are
* a README file
* a license (preferably, but not constrained to, a business-friendly one)
* actual code, to prevent a bunch of empty modules being created

4. Open accounts
Users can create accounts by logging in via twitter, facebook, etc, and link multiple sign-in methods to their accounts.

5. Security
Authentication will come via SecureSocial (so Jorge Aliss needs to start coding!) and authorisation will be implemented in Deadbolt 2. As a result, this will supercede the SociallySecure example app which showed how to integrate the two.

6. Modules are web-accessible
Modules can be downloaded directly through the browser

7. Modules are framework-accessible
Regardless of the version of Play, and therefore regardless of the dependency mechansim, the repository will serve modules directly to the framework. In other words, when you add modules to dependencies.yml or Build.scala, those modules will be fetched by the framework. Manual installation is not required.

8. Voting
Any logged-in user can vote up a module. One vote per module, to keep things fair.

9. Commenting
Any logged-in user can comment. Because of the open sign-in method, I think it doesn’t make sense to have anonymous comments. Trolls can go elsewhere.

10. Play 1 modules
Play 1 modules will be hosted directly in the repo.

11. Play 2 modules
Play 2 modules can also be hosted in the repo, but since they can also be hosted in any Maven or Ivy repo it’s possible to link to the remote repo instead. This doesn’t impact point #7 since it will be transparent to the framework itself.

12. No ambiguity
One very important point comes from Ben Verbeken – “We’ll just have to make sure it’s really obvious to the visitor that they are browsing either the play 1 or play 2 modules (no hidden filter feature, but a big red switch at the top e.g. )”

The github repository (which is currently empty, because it was created nine minutes ago) can be found at https://github.com/playframework/modules.playframework.org

At the moment, we’re purely at the planning stage but I plan to use my favourite development style (evolutionary prototying) to get something up and working fast. The github repo will be created tonight, and regular updates will be posted here.

Peter Hilton has posted some more details over at the Play Google Group.

There’s a very active discussion going on at the moment regarding Play 2 over the Google Group, and it’s really polarising opinion. A lot of people still seem to be under the impression that Play 2 is only a Scala framework, with a crappy half-baked Java API bolted on as an afterthought. It’s not – both Java and Scala are first class citizens in Play 2, and it amazes me that so much FUD is surrounding this issue.

People also seem to be viewing it as a usurper to Play 1, and that Play 1 is now a dead framework walking.

I’m going to do the laziest thing possible in a blog, and reproduce my contribution to this argument (with added emphasis on some parts):

I’ve got projects in production using Play 1.x (including a huge one that took over a year to write – and which would have taken much longer without Play). Do I think Play 1 is going to die? No – because lots of people, including Zenexity, have got lots of projects running on Play 1. For them to let it die would be like shooting themselves in the foot – got this from Guillaume and Sadek directly last night.

Do I want to port those projects over to Play 2? No – because they’re running perfectly well on Play 1, and are now in maintenance mode.

What will I choose for my next project? Probably Play 2, unless the code requires deployment as a war, and this seems to be a point that a lot of people are missing. There’s nothing that can be done in Play 1 that can’t be done in Play 2, and if you want, you can do it all in Java. My Scala is still pretty much at the beginning of the learning process, but this in no way discourages me from coding with Play 2 because *I don’t need to know Scala*. For a comparison, how many people knew Groovy before they started using Play 1 Groovy templates?

Backwards compatibility is important, and that’s why Play 1.2.5 (and .6 and .7 and .n) will be backwards compatible. For Play 2 to not be able to move past what has come before would maybe win some fans in the short term, people who want to be able to drop their Play 1 projects into Play 2 without a code change, but in the mid- to long-term it would have been obsolete before it even started.

There is no Play Scala or Play Java – it’s Play JVM, and that’s what it always has been!

For reference, the thread is https://groups.google.com/d/topic/play-framework/AcZs8GXNWUc/discussion