Monday, January 5, 2015

The Aquarium

Well this happened, I've just been featured on Glassfish's The Aquarium blog! I recorded a quick demo showcasing my thesis project and they made an article! Since they liked it and deemed it worthy to be featured there, I can only thank them for the support.

Lots more are coming. Wait and see!

Tuesday, October 14, 2014

Simple PrimeFaces CRUD Guide - READ & DELETE

In the second part of my PrimeFaces CRUD guide, I talk about the Read and Delete operations on a database. That is, to view the records of a database (either all of them or search for certain ones), select records and delete them.

In the case of my application, the idea goes like this;
the administrator navigates to the show-users webpage. Automatically, the page loads the records from the database and displays them. The admin can also search for users by username, name or email. Naturally, the display of users updates to show the new records. In any case, the admin can select a user to delete. After pressing the Delete button, the user is deleted from the database, the users' display is updated and a Growl is shown.

A video demonstrating how this works is shown below:

JSF Code

I'll be using code snippets in this post instead of a single screenshot, but you can find the full gist here.

Let's start with the form. It has only two components, a panelGrid and a dataTable.


There isn't much to explain here, the 3 columns accommodate the three components inside the panelGrid; the selectOneRadio, inputText and commandButton.


When one clicks a radio button, its itemValue is passed to the selectOneRadio and thus it can take only three values, username, name and email. By default the selectOneRadio is deselected, but I'll show you later how you can default to a certain value.


The searchTerm is what the admin enters to search the database. Like I showed in the video demo, if it's empty it just shows all the records. The title attribute is a tooltip that's displayed if the mouse cursor hovers over the component.


The interesting part here is the update attribute. It's used to force an AJAX update to the specified component, in this case the showUsers dataTable, causing it to only show the records I searched for.



Let's take a look at the dataTable attributes. The value one, is linked to a List that holds the List of objects that are fetched from the database. The tableStyle auto-stretches the dataTable to fit its contents and parent component. 

The var attribute is the iterator of the dataTable and the rowKey is used to detect which row is selected. It needs to be a unique identifier, so the user's ID field is ideal considering there are no duplicates in the database.


I think the columns are self-explanatory. The first column though is how the radioButton is added and the selection-mode attribute means that only one of the rows can be selected.


The footer of the dataTable naturally spans below and across the data. I've added indicators to show how many users there are in the database, and how many we see when we search for terms.

The deleteUser commandButton is what I'm really proud of. I don't know if there's an easier way to do this but I managed to make it work how I want it. It may be trivial to some people but I've never worked with web technologies before.

When I want to delete a user from the database, I want both the dataTable to update and the Growl to display the deletion message. The update attribute though can only update one(?) component. So what I thought was; update just the Growl but set the commandButton's ajax attribute to false! This would force the page to refresh and then reload the data from the DB. 

JSF Backing Bean

Full gist can be found here, I'll just show the key methods below.


In the constructor you can see that I set the searchBy value to username. This defaults the radio buttons to pre-select a specific value. It's quite handy if we forget to select what to search by.


The if statement is a work-around to exception handling, this code here should be re-written with exceptions I think, throwing one when the search input text is empty.


In the first part of my guide, I mentioned that EJBs cannot be instantiated in the backing bean's constructor. This is why I'm using the PostConstruct annotation, the init method is called after the backing bean is constructed and in this case fetches the table records and counts them.

Entity Session Bean

In the enterprise java bean (gist here), lies the code that communicates with the database. The show-users webpage has some calls to the EJB that queries the DB using JPQL.

JPQL Search

The findAllUsers method's query is the equivalent of SELECT * FROM Users, we fetch all of the records.

It returns a list that holds the results of the specific query. The RolesAllowed annotation specifies that only the app users with the admin role can call this method.

When we want to search by name, a similar query to SELECT * FROM Users WHERE id LIKE '%sth%' needs to be constructed. The task is accomplished like so:

Java8 Search

Now that we have Java 8 and GlassFish 4.1 has support for it, we can use the Collection improvements (streams, filtering, lambdas) to accomplish the same thing as above. In the example below, I fetch all of the records from the database and store them in a List.

Each element of the list is streamed and filtered with a lambda expression, if it matches the argument it's placed in a new List.

Keep in mind though, if the database was large there would probably be a performance issue here. I hardly think the Java 8 streams are as optimised as a native SQL query.


In order to delete the selected user, the object must be passed as an argument and then execute the query. The User argument is an object in the backing bean code that has its properties set when the admin checks a row in the dataTable.

When the query is executed though, it returns an integer that denotes how many rows were affected. Since I don't need the affected rows (I just delete one user at a time), I just assign the query to an integer and don't use it.

Coming up next...

In the third and final part of this guide, I'll be talking about the the UPDATE operation of CRUD, updating an existing DB row. I haven't written the code for that yet, so it may take some time for the 3rd part to come up. I have to see how I can transfer data from one webpage to another.

Sunday, October 12, 2014

Simple Primefaces CRUD Guide - CREATE

I've been wanting to start this series of posts for some time now, finally I have a nice working project and can put into words what I've learned over the last months with JavaEE 7.

Now, do not expect to find here anything ground breaking, it's just my progress while I learn JavaEE 7 and many things are subject to change while I learn more. Many things are probably not done the "correct" way and lack proper functionality, but like I said it's a constant work in progress until I finalise my project. Right now for the code, I don't take into consideration false input and/or exceptions. Those will come later. Also, I may make mistakes or have misunderstood something, feel free to correct me.

Mostly I'm using the official PrimeFaces documentation, showcase and forum, various Youtube videos and of course stackoverflow.

Before we begin

Make sure you have a working persistence unit, I'm working with NetBeans 8.0.1, GlassFish 4.1 and JavaDB. I followed this fantastic guide to setup my environment and it works perfectly. I use the same User and Group tables as in the video because the users will log in to the system.

Also, what I'm showing here are from an imaginary DB admin's perspective, nonetheless any CRUD operations in any point of the application should be more or less the same.

Desired form

The case here is that the admin wants to add a new user with the specified credentials, either as a normal user or as admin.

JSF code

Let's take a look at the JSF code (gist here).
Well, the form is what will be submitted and its values stored to the database. The PrimeFaces panelGrid element allows us to create this really good looking grid with elements. 

Its column attribute is self-explanatory and works like this; the first element (facets excluded) will be placed in the first column, the second in the second column, the third in the first column and so on. That's why I'm alternating the outputLabels and inputTexts.

The selectOneRadio element is a really useful one, we can group radio buttons and select only one of the bunch. I think this functionality isn't present in vanilla JSF, we'd have to employ JS scripts to do that. Haven't looked too much into it though, don't take my word for granted.

The inputTexts have a required=true attribute. It means that the value cannot be empty. Like in every registration form online, some fields are required and some are optional. If the attribute was set to false or not set at all, the field would be optional and could accept empty values. The requiredMessage is a simple message shown if the user tries to submit the form and leaves some inputText empty.

This is what happens if the form is submitted with a couple empty fields:

The two commandButtons process the form, the Cancel one clears the form and the CreateUser one saves the User. The commandButtons' behaviour in PrimeFaces is to update with AJAX, in this case I din't want to update with AJAX so I set the ajax attribute to false. The action attribute can be either another webpage to navigate to, or a method in the backing bean.

The messages and growl elements are a way of showing messages to the client.

JSF Backing Bean

When it comes to processing data, the webpage can't do much. So far, all we've done is set up a usual web page with JSF notation. The data must be passed to Java classes to be processed, every JSF page must have a backing bean if it deals with data. Gist can be found here.

The RequestScoped annotation is used because the backing bean will be used once per form submission and doesn't need to maintain data. I'm still a bit fuzzy on the scopes so...

The Named annotation "renames" the backing bean for ease of use. The class name could be "BoogieBoogie" or anything else but I'd rather use the createUserJSFBean name in the JSF page.

The two EJBs are the objects that will persist the data to the database, they are injected and cannot be instantiated in the constructor since the lifecycle of the EJBs is controlled by the container. They will be invoked when they're needed.

The private User and Groups objects are used to be passed as arguments in the respective EJB create methods. They aren't necessary, just useful.

The following five Strings are the actual variables that hold the values of the JSF page. They need to have getters and setters otherwise the JSF page can't access them.

Next, I have the createNewUser method which is called by the Submit commandButton. It calls the helper inputCredentials (just to set the form values to the User and Groups objects), calls the EJBs' create methods to persist the data, displays a simple Growl to show that user was created, and empties the form fields using the clearInputCredentials method.

Entity Session Beans

The session bean communicates with the database and performs queries to it. NetBeans generates some really useful classes. Gist is here.

The abstract class this one extends, has some basic functionality which is really handy. Methods for creating, editing, removing and finding entities are present in the abstract class. In this case, I'm overriding the create method because I want to add some more code.

The PasswordHasher is a helper object (it includes Google Guava) that generates SHA-256 hashes of the given password. It's not wise to leave the passwords in cleartext, some type of hash needs to be applied.

When I created the database I forgot to set the ID column to auto-generate values, so now I have to manually assign values to the ID fields of the users. That's no problem when I have the findMaxID method. It fetches the maximum value of the table's ID column and increments by 1 when I set the user's ID.

And that's it.

Coming up next...

In the next part of this guide I will show how I implemented the showing and deleting of users. Much more interesting in my opinion and a little bit of Java8 will be shown.

Wednesday, August 20, 2014

DZone - Favourite Netbeans features

Recently, I was asked by Geertjan Wielenga to present my 5 favourite Netbeans features. I've been tweeting a lot about Netbeans the past few months because I was really excited about the stuff I found out about it, it really is a great IDE and makes my life a lot easier.

So, here is my article

and here are a lot more Netbeans users presenting their favourite features.

Tuesday, May 13, 2014

Bye bye Dropbox...

Ήρθε πια η ώρα να πούμε αντίο...

Καλό πρόγραμμα, πολύ εύχρηστο, απίστευτα βολικό για sync μικρών αρχείων μεταξύ διαφόρων συσκευών, για μένα όμως ήρθε η ώρα να το παροπλίσω...

Γενικά δε το χρησιμοποιούσα απ' τη στιγμή που έβαλα το Google Drive, τι να πουν τα 2,5GB του Dropbox όταν το Google Drive μου δίνει 50+ GB δωρεάν. Βέβαια τώρα το Dropbox λέει ότι έχω 50GB χώρο, αλλά αυτό εξαιτίας ενός promotion της Samsung (ήταν το προηγούμενο μου κινητό) το οποίο λήγει στις αρχές του '15 και φαντάζομαι θ' αφαιρέσουν τα 48GB της προσφοράς.

Δύο sync προγράμματα δεν έχουν πολύ νόημα, το ένα έχει και το Google Docs οπότε κερδίζει με μεγάλη διαφορά. Αυτή τη στιγμή στο Dropbox δεν κάνω τίποτα που να μη μπορώ να το κάνω μέσω του web interface του. Θα το κρατήσω εγκατεστημένο μόνο στο κινητό επειδή έχει το Upload Photos, αυτό ναι είναι πραγματικά καλό feature.

Το GDrive όμως έχει κάπως περίεργο sync, αν το απεγκαταστήσεις προφανώς μένει ο κατάλογος που παρακολουθεί τ' αρχεία. Αν το εγκαταστήσεις μετά και του δώσεις να παρακολουθεί τον ίδιο κατάλογο, θα σου πει ότι έχει ήδη αρχεία και πρέπει να τα σβήσεις! Θέλει να κατεβάσει όοοολα τ' αρχεία που έχεις στο Drive σου. Είναι χαζό. Όχι όμως και τρομερό πρόβλημα.

Οπότε αγαπητό Dropbox χαιρετώ...

Monday, May 12, 2014

The Hunger Games: Catching Fire


Χωρίς πλάκα μια απ' τις καλύτερες ταινίες που έχω δει ποτέ! Δεν υπήρχε περίπτωση να περιμένω αυτό που έγινε στο τέλος...

Παρόμοιο σοκ έπαθα όταν είδα το Νησί (Γιούαν ΜακΓκρέγκορ, Σκάρλετ Γιοχάνσον) πριν από τόσα χρόνια, και δε λέω εύκολα κάτι τέτοιο για ταινία όσο και να μ' αρέσει.

Μακάρι να την είχα δει στον κινηματογράφο...

Friday, March 14, 2014

DietOnJava - JavaFX desktop app

Well, this is my project and this post is an overview of it, I'll explain the basics although it's pretty straightforward as you can tell from the GUI.

I'm making an application for a friend of mine, he's a dietitian and asked me if I could make him an app to create diet programs for his clients. Yes, there are many similar programs (professional ones) out there but he wanted a specific GUI and also this would be a great exercise for me, although I'm a noob Java programmer.

Do NOT expect awesome code and such, I have some experience with Java yes, but this will be my first full-application with JavaFX, GUIs, DBs etc. Also, I haven't implemented any functionality yet, I'm questioning whether I should continue like this or re-write it with another approach, you tell me.

Dev Environment:

I've started building the application on NetBeans 7.4 (now using 8 RC1), Java7 SE and Scene Builder 1.1. Scene Builder was used to create the FXML layout, it's extremely easy this way.

I have an SQLite database that holds the food data, it's a single huge table with all the data, certainly not the most optimal solution but hey, this is my first try on developing something like this.


The Main DB tableview, shows the SQLite database. The buttons below it are self-explanatory, they add, edit and delete entries from the database.

Above the tableview, the client's info are entered and you can select a picture if you like.

The tableviews to the left constitute the diet for each day, you have 5 meals for each day plus a tableview that holds the total sums for each nutrient (total water, total iron, total cholesterol etc).

Foods are added to the meals by dragging and dropping from the main database, to delete foods from the meals maybe double clicking, I'm not sure yet.

This whole screen will be saved probably to XML documents, you'll have a single XML document for each diet schedule. Or JSON, I don't know. I've found libraries that do that so it'll be easy I guess.


That's basically it. There are no "blueprints", no UML, nothing. I look at the GUI and try to see what needs to be done. Since it's object interaction, it's kind of clear what I need to implement.

I haven't worked on the application for a couple of months due to uni exams, I'm really excited to pick it up again but I'm debating whether I'm on the right thought process or not.

ANY kind of feedback would be extremely helpful, I'm here to learn anyway. I have the project on GitHub under a Creative Commons license so feel free to take a look at my (now quite nonexistent code).