SWT File Dialog

During the development of an Rich Client Platform (RCP) it is common to develop a file browse dialog, here’s how to show a file dialog in SWT:

import org.eclipse.swt.widgets.FileDialog;

FileDialog dialog = new FileDialog(this.getShell(), SWT.NULL);
dialog.setFilterExtensions(new String[] { "*.txt", "*.*" });
dialog.setFilterNames(new String[] { "Text files", "All files" });
String path = dialog.open();
if (path != null) {
   File file = new File(path);
   if (file.isFile()) {
     System.out.println(file.toString());
   }
}

The snippet above filters by text files (*.txt) and all files (*.*) and it is easily applied to the click event of any button or file menu option.

Intenationalize RCP applications

To internationalize (i18n) and Rich Client Platform (RCP) application, also known as Eclipse Application, it’s not enough to download the language package. One also needs to download the language packs for the RCP core.

Here’s what it takes to i18n the core of an RCP application:

  1. Download the language packages from the Babel project using the Eclipse install/update mechanism.
  2. Open the RCP application “.product” file.
  3. Go to the “Configuration” section.
  4. Press “Add Required Plug-ins” button.

This last step is the “magical step”, it includes the i18n plugins to the RCP application.
You can identify the language plugins by their name. They come in the “<plugin>.nl_<language>” format. For instance, Portuguese JFace translation file is “org.eclipse.jface.nl_pt”.

Drupal vs Joomla!

Hexónico has launched a free item exchange service for the Portuguese speaking community: Trocaqui.
It was implemented using Drupal, for the user front-end, and that raised a lot of questions. Many people asked me, “why Drupal and not Joomla!” and “you’re using a CMS, what’s the difference between Drupal and the others“.

So, I’ve decided to write a bit about the Trocaqui project and why Drupal.

When the project started, obviously some options have been evaluated: writing from scratch, using a framework, using a CMS, etc..
Writing from scratch was out of the question, since it would consume too much time to achieve the quality and functionality some systems already provided. The same applied to the usage of a framework that would left all the hard work to the developers. Mambo, Joomla! and Drupal are all CMS references.
From those, Mambo is an old friend, which has been dropped in favor of Joomla!, since it is like the natural evolution of Mambo.

After some analysis, it came to the point where it was either Joomla! or Drupal. Some tests were performed to see which would respond best to the main requirements:

  • Translatable (i18n for Portuguese)
  • Easy to use for the end user
  • Extensible
  • Expandable
  • Forum support
  • Image management support
  • Flexible and easy user access configuration setup
  • Easily costumizable

The tests started by setting up the systems which was an easy task for both of them.

Install

Joomla! is ready to be used just out-of-the-box. It allows one to manage text and images, it comes with a WYSIWYG text editor and is quite easy to understand. Almost everything is where one expects it to be. So, finding an option and using it is straightforward.
On the other hand, Drupal is not so usable out-of-the-box. It just supports text and doesn’t came with an WYSIWYG editor.
So, some additional modules were necessary in order to expand Drupal to support my needs.

When it comes to module/plugin installation, in Drupal it is totally manual, so are the upgrades.
One has to uncompressed the file contents into a specific directory, the go to the modules section in the administration menu to activate it. Then one has to configure it.
Sometimes this is not as easy as it seems and some technical background is required in order to setup things correctly.

Core Modules

Drupal does not come with a WYSIWYG text editor.
Since I needed a rich text editor, I had to test editors before selecting one that worked as I needed. It was a bit painful because I had to test some and that took more time than I was initially expecting.

Drupal does not come with an image module.
A content management that cannot manage much beside text is not very useful.
Thus, the quest of an image module began. I’ve found Drupal has many modules that support images. And I’ve also found out that the reason for this proliferation of image modules is that because they all suck. There’s not one good image module for Drupal, so it seems that everyone that needs one, develops one.
After some digging and testing, I’ve finally found an image module that suited half my needs. After some more digging, I’ve found another module that was suited for the other half of my needs.
Everyone that needs images on their CMS should check if Drupal modules fit their needs before going for Drupal.

How They Work

Drupal working philosophy is not straightforward.
In Drupal, things are not were one expects it to be. It works with a organization and, to me, it complicates things, making it far more complicated that it should and needed to be.
Even today sometimes I take 10 or 15 seconds looking around for a specific option. It is not administrator friendly, specially if you don’t work with it often.

None came with a forum solution, so I had to install one on each of the systems.

Finally I’ve finished setting up the systems.
Drupal had been painful so far, and I was loosing some consideration about it. But people do refer to it as a great CMS, so I decide to continue according to my plan.

It was time to evaluate things regarding my functional needs.
An here’s the turning point favoring Drupal.

Joomla! does not come with flexible user parameters. But Drupal does.
In Drupal, the core user module allows one to defined specific parameters and corresponding value types in a very easy way. Probably Joomla! allows it to, but I didn’t invest much time searching for such a module/plugin.

Joomla! does not allow drag-and-drop.
In Drupal, it is easy to move things using the mouse, just drag that menu option and drop it where you want it, do this option as many times as needed and the push the save button. This seems a minor issue, even from me (I’m a less WIMP than the average), but the amount of work that I was performing with such easiness allowed me to be far more productive than doing the same similar task in Joomla!.

Customization

Everything was going fine until a show stopper bug was found. There was so many exchange categories that Drupal stop ignoring the specified exchange category order.
Not even the weights were working. Even banging directly on the database the items were not showing up in the correct order.
This forced to stop the project for some weeks while finding the solution.
There were other complaining about this bug, it is know for years but yet, Drupal seems to be ignoring it.
This problem has been posted this in Drupal forum but the lack of answer was starting to put this project on a failure risk because it seemed that there was no solution .
But suddenly, a specific module for this problem came from Ben. He was just fantastic in helping with this problem, he developed a small module, with a few lines of code, that solved the problem. Trocaqui was on the move again.

Next, it was necessary to create a template for the user to use when posting a new exchange item.
This revealed the true power of Drupal and why technical people love it. In Joomla! One needs to modify the forum module source code and use that modified module and, when a new version came out, do the same.
In Drupal I only needed to create a hook. A hook is like a handler that overrides the original code. One just say, when this event happens, that one wishes to do such and such. It was not easy to find out the correct data in the data structure that needed modification, specially when one is new to Drupal programming. But once the correct data was found, it revealed simple, easy and clean. The simplicity was dazzling and by then there were no doubts whatsoever that Drupal was the way to go.

Translating things to Portuguese also revealed much easier in Drupal. Both systems do have translation files for their modules, but Drupal allows one to translate things on the fly. Drupal has a translation interface that does not require the user to edit the translation file and upload it into the server.

Permission configuration also revealed a bit simpler in Drupal. I’ve just configured the read, write and administer accesses of each module for registered and non-registered users.

Finally it was necessary to create a specific home page to show to everyone that landed on the site.
Since by then Drupal was already selected, this was not even tried in Joomla!.
In Drupal there’s a specific front page module that is just fantastic. There were two pages created: a specific home page for non authenticated users and another to authenticated users. It was just simple.

Conclusion

After all this quest here’s the lessons learned:
Joomla! is recommended for non-technical people and for web sites that do not require awkward requirements. It’s a great out-of-the-box solution and much easier to work with. But when things get though, one needs a technical person and one wants Drupal supporting your site, even if it costs a lot of time to learn how to use it.

JPA Persistence/Transactions

When involving several calls to your DAO methods in a single transactions, here’s a great place to start: Java Persistence/Transactions

Here’s a small stub for kick-off:

UserTransaction tr = null;
try {
  tr = (UserTransaction) new InitialContext().lookup("javax.transaction.UserTransaction");
  tr.begin();

  bean.op1();
  bean.op2();
  // ...
  bean.opN();

  tr.commit();
} catch (Exception e) {
  logErrorMessage(e); // log error message

  if (tr != null) {
    try {
      tr.rollback();
    } catch (Exception e1) {
      logErrorMessage(e); // log error message
    }
  }
}