Saturday, January 21, 2012

JPA and Vaadin JPAContainer

I've been finalizing the completely rewritten chapter about Vaadin JPAContainer this week. I still need to check that everything really important is included.

I don't have almost any previous experience with JPA, which is kind of good thing when you write documentation about something. That way, you personally know all the questions a beginner would have.

JPA and ORM in general seem pretty important technologies. Whatever your application is, you most probably need some data storage. Using ordinary files is possible, but not near as handy as proper databases. However, stuffing complex class structures through the square holes of database tables was a hell before the ORM technologies emerged. XML databases and NoSQL were much nicer for structured storage.

Some years ago I did some experiments with related technologies, such as JAXB and Hibernate, but using them was a bit too much effort at that time. Using Hibernate with Vaadin really required a Container implementation, but there wasn't one at that time. Well, JPA is quite close to Hibernate, and Hibernate is currently one of the JPA implementations.

Vaadin JPAContainer makes things really easy.
// Create a persistent person container
JPAContainer<Person> persons =
JPAContainerFactory.make(Person.class, "book-examples");

// You can add entities to the container as well
persons.addEntity(new Person("Marie-Louise Meilleur", 117));

// Bind it to a component
Table personTable = new Table("The Persistent People", persons);
personTable.setVisibleColumns(new String[]{"id","name","age"});
layout.addComponent(personTable);
So, just one command to get a container bound to data in a database table. JPAContainer is, however, just for binding user interface components directly to data. You can use it to add or edit the data, but using pure JPA is much nicer, easier, and more flexible for that.
EntityManager em = JPAContainerFactory.
createEntityManagerForPersistenceUnit("book-examples");
em.getTransaction().begin();
em.createQuery("DELETE FROM Person p").executeUpdate();
em.persist(new Person("Jeanne Calment", 122));
em.persist(new Person("Sarah Knauss", 119));
em.persist(new Person("Lucy Hannah", 117));
em.getTransaction().commit();
Well ok, here we got the entity manager from the JPAContainerFactory, which makes that a bit easier than normally.

JPAContainer is a commercial product. That shouldn't be a problem if you're coding for a company that can pay the license. For free software, you can use the AGPL license. I've always felt that this sort of dual-licensing scheme is most difficult for "potential startups" where you experiment with a business idea, but do not yet have a company to back it up financially. You do not normally have the money to invest in licenses at that point, and a company might not want to invest much in such experiments either.

There are of course alternatives for JPAContainer. Using pure JPA is quite OK approach as well, combined with BeanItemContainer in Vaadin. There's also SQLContainer. It is also something I don't know about, as I didn't write the chapter myself. I would need to review and reorganize it in next weeks though, and possibly rewrite at some point.

Well, I did make a couple of mistakes while writing the JPAContainer chapter. The first one was trying to just update a really complex design documentation written by someone else, in a topic I knew nothing about. Writing is always a learning experience and it's not sensible to try to write about something very complex that you don't have a clue about. Sometimes, it's best to start from scratch. Unfortunately, I didn't do that when I started, but just over a week before the release.

Another issue is learning by doing. I usually start writing documentation by experimenting how it works, making some example code. This time, as I was in a hurry, I tried to skip that phase. I only started it as the last effort when I was totally stuck, some 4 weeks of struggle behind and 2 work days before the release date. Just in those couple of days, all pieces fell into place and I finally understood how everything works.

Wednesday, January 18, 2012

Wikipedia and Antipiracy Laws

So, if you have noticed, we've had a Wikipedia blackout. I normally use Wikipedia to look up dozens of articles daily, so I'd be pissed if their protest wasn't really valid.

As innocent they sound, the "Intellectual Property" laws are a big threat, really. They are somehow understandable, which is the reason why they exist, but at the same time, they may be a big threat to modern civilization.

You might think that they are not a problem to you, as they only prevent criminals from making crimes. You might even think that you want your intellectual properties be protected.

Their aim is to prevent illegal copying. Artists and others work so that they would get paid, and illegal copying is kind-of stealing from them. So, forbidding illegal copying is rather understandable.

So what's the fuzz about?

Let's consider the problem with DVDs. They use the "CSS" encryption mechanism to prevent unauthorized copying. Fine, excellent, evil pirates suffer, right?

Unfortunately, watching CSS-encrypted movies requires special software that holds a special decryption key. The software is usually free-of-charge, but it's only for Windows, and perhaps for Mac as well. For Linux, which I use, there is no such authorized software for watching DVDs.

Fortunately, some Norwegian guy cracked the CSS key and wrote a decryption algorithm some 10 years ago and now there's "DeCSS", an algorithm to play (and copy) any DVDs.

So, over the years I've bought some 200 DVD movies and I've always watched them with Linux and nothing else. I've never copied a DVD that I've bought, only watched them.

However, using the DeCSS algorithm for any purpose is illegal in Finland. It's been tried in court.

The fact is that, once cracked, CSS became totally obsolete forever. The laws will never have any effect on unauthorized copying. But they will continue to prevent morally right use of your property.

So, pirates who operate illegally of course use the DeCSS decryption to make one copy which they then copy to millions. But people like myself, who buy DVD movies legally, are criminals. Trying to stop a few criminals, they incriminate perhaps millions of Linux-users around the world.

So why should you care? Linux users are somewhat rare, and you're probably not one of them (except if you use any of the 60% of the web or 55% of smartphones or a TV).

Oh, but it also affects Windows users. There's free DVD watching software for Windows as well, such as VLC, which is actually quite popular as it's very good. But it's illegal, as it has to use DeCSS. The laws prevent writing and distributing any free software that you could use to watch DVDs.

Obviously, preventing the use of free software to watch legal DVDs was not the purpose of the laws. It's just a consequence.

It's a good example of a case where somewhat understandable reasons lead to absurd results. Even so, the vast majority of the Finnish parliament supported the law. And there is a lot more IP legistlation on the way.

Oh, did I mention that Finnish consumers can legally copy movies and music for their own use and to friends. We even pay a tax for that when we buy DVD-Rs. But copying by circumventing CSS is illegal.

Given the absurd criminalization and heavy anti-"piracy" lobbying to take away your rights, you should have no sympathy for the movie industry. O'hoy pirates! Go and board them!

So, to SOPA or PIPA...

I'm not personally familiar with the new legistlation initiatives in the USA. As far as I've understood, it's something similar as the recent Finnish laws that allow blocking child porn and peer-to-peer download sites. The laws already have a sad history of abuse. For example, the laws do not allow blocking websites inside Finland, but they've nevertheless done so as there's no possibility to legally challenge the decisions.

The pattern is that "reasonable requirements" can have devastating effects. The current laws are largely based on the assumption that you are responsible for your own publications. The suggested laws place the responsibility on the owners of web servers and internet providers. So, if me or you were to publish the DeCSS code here in the blog, the Blogspot would be considered the "publisher" that is responsible for our writings. To protect itself, Blogspot would need to have editorial review for everything any one of the millions of bloggers write.

This would quickly kill almost all blogs, discussion forums, and websites in the Internet. Also Youtube and such. It would kill the basic freedoms that we take for granted, and most of the Internet.

Part of the Finnish goverment already has plans to expand the blocking further. Some want to block information about drugs and weapons. Then racism of course, blasphemy, information about bombs, porn, denying the Holocaust, undemocratic thought, ... anything to protect the children, leaders, gods, and corporate owners.

Even though basic IP laws may be necessary, the recent development upholds corporate ownership rights over consumer ownership rights. They are used to buttress dentrimental monopolies and force you to pay vastly overcharged prices, even for basic necessities. They distinguish diversity and freedom, which are the life forces of the modern technological and scientific ecosystem.

So when you see the blackout screen at Wikipedia, just imagine the day when it could be blacked out by your government.

Tuesday, January 3, 2012

Vaadin IPC for Liferay add-on

For Vaadin users, I just finished writing documentation for the Vaadin IPC for Liferay add-on yesterday. The version 1.0 of the add-on will be released tomorrow I think. The add-on is very very useful if you want to have two portlets that communicate with each other on the same page. The add-on uses standard Liferay JavaScript event API, so the other portlets can be any Ajax portlets, not just Vaadin.

Here's how it works:


As a side note, I really like Inkscape for drawing those diagrams. Well, I have no clue how wonderful some "best-of-the-best" vector graphics apps are. But I seem to be able to do practically everything with Inkscape and, after a while, it's not so hard to use. I've also done a nice production pipeline so that I can just save the pictures as SVG and the build scripts for the book do the exporting to PNG automatically. It's not even hard, just one command-line call.

The LiferayIPC is a Vaadin component that you add in the main window (layout). The inter-portlet communication is done between the client-side widgets.
LiferayIPC liferayipc = new LiferayIPC();
layout.addComponent(liferayipc);
...
liferayipc.sendEvent("hello", "This is Data");
To receive an event in other portlets, you define a LiferayIPCEventListener as follows:
liferayipc.addListener("hello", new LiferayIPCEventListener() {
public void eventReceived(LiferayIPCEvent event) {
getWindow().showNotification(
"Received hello: " + event.getData());
}
});
The add-on package includes this nice demo WAR that you can just deploy in Liferay. It demonstrates how to send and receive inter-portlet events.



You can combine this client-side communication method with server-side inter-portlet communication, for example, by using portlet session attributes. You may need to do that for security reasons or if you need to send large amount of data. In such case, you just send a client-side notification that says: "Hey, there's new server-side data available, read it now."

So, go ahead and read the new section in the Book of Vaadin. It explains everything. If it doesn't...go and ask in the Vaadin forum.