Dynamically Changing the Structure of a Grid in ExtJS 4.2

If you have a grid in ExtJS, it might happen that you want to change the columns of the grid depending on the data you receive from the server.
In my new pet project Bulks I was facing this exact problem, so I thought it might be worth sharing the solution with you.
In the example below we try to render differently structured JSON arrays in the same grid. The function getKeysFromJson retrieves the keys from such an array. With this
information we can build the ExtJS columns array easily in the createColumns function by mapping each key to a column definition object.
The function createStore further shows us how to create an ExtJS store from the JSON and the keys array.
The store and the columns array are needed to call the reconfigure function of the ExtJS grid which changes the data and column layout of the grid.
Play with the following small example – I hope it demonstrates the idea:

BTW: Don’t wonder about the Chinese characters, I am just trying to learn that language and as everyone I am very happy being able to write my first characters…

Adding Buttons in a Dataview using ExtJS 4.2

If you have a dataview in your ExtJS application, it might be possible that you want to add some action buttons for each of its items. With some good old Javascript this is actually quite easy.
You just have to create a template that contains the HTML markup for the button and give it a distinguishable class name. In the itemmousedown listener of the dataview you later check for the class name.
Here’s a small example that uses this approach:

Securing Your Play 2.1.1 Web Application Using a Filter

After deploying my Play 2.1.1 based application to Cloudbees, I had the problem that everyone could access it. Not very ideal if you want to restrict your program to only a single audience.

To solve the problem you would usually write a complicated user-based authentication system. Slightly an overkill, if you don’t need different users accessing your program at all. My idea was more that the user has to add an URL parameter with a secret key, the first time the application is called. For later requests the key would just be stored in the session object.

That way you basically access the program via the following URL:
http://myapp.cloudbees.net/?access_key=secret
instead of just using:
http://myapp.cloudbees.net

The solution is quite simple. You just have to add a Filter that is checking every request. If the desired URL parameter is passed the request will be processed as usual. If not, we just log the potential threat and return a 404 (IMHO way better than returning a 401 and motivate the intruder that way to hack your site).
Let’s have a look at the following object called AuthFilter:

Don’t blame me if the code above is not ideal – it’s not only my first program using Play but also using Scala.

To activate the filter, you have to enhance the Global object (store it in the default package):

You may wonder about the method validSession in the AuthFilter. It’s purpose is to add a valid token in your unit tests. Here’s an example with a FakeRequest to /:

Have fun hiding your applications! Don’t forget that the secret key is transferred unencrypted. So if you need some extra security, add SSL. Unfortunately this cost something on Cloudbees….

How to use JSF 2.2 with JBoss 7.1

As the new JSF 2.2 is nearly finished, we all want to play with the new features of it.

Markus Eisele has shown in his blog post Testdriving Mojarra 2.2.0-m08 how to do this with Glassfish 3. He’s German too, I begin to wonder if only we guys are that curious or no one else is using JSF any more 😉

Unfortunately with JBoss 7 we face the same problem he had: We can not just add the new libraries to our WAR archive as they will clash with the JSF 2.1 version of Mojarra (the reference implementation of JSF) already provided by JBoss 7.
So basically we have to disable this old version and activate the new version directly in the application server.

I will show you how to do it with JBoss 7.1.1 and the M08 release of Mojarra 2.2, but it should work for other versions the very same way:

JSF is divided into two parts: The implementation and the API.

We firstly exchange the former one by starting to download jsf-impl-2.2.0-m08.jar, which is the JAR archive containing the implementation.
After downloading, copy this archive to the folder of the old JSF implementation of your JBoss installation, which will be %JBOSS_HOME%/modules/com/sun/jsf-impl/main in that case.
In the same directory you will find a file called module.xml. Edit it and change the contents of the resources tag like this:

This is important as it tells JBoss which of the provided JAR archives (now there are two of them) to use. If you want to know more about this: Take a look at JBoss Modules, a module class loading approach JBoss 7 is using.
After that you have finished with exchanging the implementation and basically you have to do the same for the API part:

Firstly download the jsf-api-2.2.0-m08.jar archive and copy it to %JBOSS_HOME%/modules/javax/faces/api/main. Secondly edit the module.xml in the same directory by exchanging the resources tag:

Basically you should be finished now, but there is a bug in the milestone 8 of the API that it has a dependency to the implementation. For that reason you have to declare it by adding the following contents to the dependencies tag of the same module.xml file:

After that you can restart your modified JBoss instance. As JSF is lazily loaded you have to deploy a WAR referencing JSF to check whether our changes work. If so, you should see a log message like this:

[javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-2) Mojarra 2.2.0-m08

Finally, if you want to use the new features in application, you have to add the following dependency to your pom.xml:

And now have fun using JSF 2.2!

Doing EJB-like transactions with Google App Engine

Using Google App Engine you can’t define a method as transactional with a simple annotation as you can in EJB.
You always need to call some boilerplate code which gets quite annoying.
Therefore the following utility class comes handy, which takes care of the transaction handling for you:

To make use of it, you have to set the same persistence unit as in your persistence.xml configuration file first. Do this by changing the parameter of the method createEntityManagerFactory.

After that you can easily define transcation boundaries like this:

In this example the transaction method has a return type of String – change this if you need a different one.
The transaction is always starting a new transaction, similar to REQUIRES_NEW in EJB (more about that in the Java EE 6 tutorial). If you want to use another transaction strategy, you will have to modify the code.
It is still not as easy as setting an annotation in EJB, but way better than without. If you want to define transactions for Google App Engine via annotations, you will need some DI engine like Guice or CDI, but then you add a lot of other code that you probably don’t need.