Vi siete mai trovati nella condizione in cui dovete inserire un immagine all'interno di una cella di una tabella (magari in modo dinamico tramite jQuery) e, in seguito all'inserimento, la cella risulti inspiegabilmente di dimensioni leggermente più grandi rispetto alla vostra immagine? Io sono incappato in questo problema inserendo piccole immagini 20x20 in una griglia, durante lo sviluppo di Battaglia Navale in JavaScript.

Credendo di essere finito in qualche variazione del box model generata in modo automatico dal browser ho impostato le proprietà margin e padding a 0, senza ottenere successo.

Il problema si risolve agilmente impostando font-size a 0. In questo modo eventuali caratteri speciali all'interno della cella non aumentano la sua dimensione, consentendo all'immagine di adattarsi perfettamente.

Closures

In questo nuovo appuntamento parlerò di closures. Come per quanto riguarda l'hoisting, le closures sono un concetto fondamentale per comprendere appieno la potenza di JavaScript, in quanto permettono di creare funzioni personalizzate che vincolano le variabili in un ambito. Sono usate generalmente per costruire funzioni di callback.

Una buona definizione di closure si può trovare sul sito Mozilla Developers Network, da cui questo articolo prende ispirazione:

"una closure è un oggetto particolare che combina due cose: una funzione e l'ambiente in cui la funzione è stata creata."

Per capire meglio partiamo con un primo esempio:

function init() {
  var myName = "Mauri";
  function displayName() {
    alert(name);
  }
  displayName();
}
init();

la funzione init() crea una variabile locale myName (che possiamo considerare come parte dell'environment o ambiente) e definisce una funzione interna chiamata displayName(). Questa funzione dispone della variabile dichiarata e inizializzata nella funzione esterna. Il funzionamento di init() è intuitivo ed è un semplice esempio di functional scoping, nel quale le funzioni annidate possono accedere alle variabili dichiarate all'esterno.

Ora proviamo a modificare l'esempio come segue:

function makeDisplay() {
  var myName = "Mauri";
  function displayName() {
    alert(name);
  }
  // NB: una funzione è una variabile,quindi può essere ritornata
  return displayName;
}

var display = makeDisplay();
display();

Il comportamento di questo codice è identico a quello precedente, potete provarlo comodamente su jsFiddle. Ciò che distingue questo esempio è il fatto che la funzione interna viene ritornata dalla funzione esterna prima di essere eseguita. Intuitivamente ci si aspetta che, terminata l'esecuzione di makeDisplay(), la variabile interna myName sia cancellata dallo stack (come avviene nei linguaggi della famiglia C) e non possa venire referenziata da display(), tuttavia l'esecuzione del codice dimostra che la variabile è ancora accessibile è può essere utilizzata.

Questo peculiare aspetto è propro ciò che caratterizza le closures. La variabile myFunction "racchiude" al suo interno la funzione displayName() e le eventuali variabili accessibili alla funzione durante la creazione della closure. Un esempio (variazione spudorata di quello su MDN) un pochino più complesso può essere il seguente:

function increment(base) {
    this.base = base;
    return function(value) {
        return base + value;
    }
} 

var addTo5 = increment(5);
var addTo14 = increment(14);

alert(addTo5(5)); // output: 10
alert(addTo14(3)); // output: 17

La funzione increment in questo caso è un esempio di function factory, ovvero una funzione che aggiunge un valore specifico all'argomento passato. Questa function factory è stata utilizzata per creare due nuove funzioni (addTo5 e addTo14) che impostano rispettivamente, nel proprio ambiente, i valori 5 e 14 come base a cui verranno aggiunti gli argomenti passati (5 e 2). addTo5 e addTo14 sono quindi closures.

E' importante ricordarsi che le variabili interne sono passate per riferimento e non per copia:

function dica33() {
  var num = 32;
  var showAlert = function() {
    alert(num);
  }
  num++;
  return showAlert();
}

var show33 = dica33();
show33();

Per oggi mi fermo qui, ma non è detto che in futuro possa portare ulteriori approfondimenti sul tema.

Hoisting - Sollevamento

In questo post parliamo di JavaScript. Di recente mi sono riavvicinato a questo linguaggio, dopo molto tempo in cui ho cercato di tenermene alla larga, per ovvie ragioni (incompatibilità, scarsa tipizzazione, ecc.). Tuttavia lavorando sulla tesi di laurea ho cominciato ad apprezzare questo linguaggio e a capire quanto può essere potente se utilizzato nella maniera giusta.

Pertanto, in questa serie di post su JavaScript, cercherò di analizzare quelle piccole sfumature che rendono poco intuitivo questo linguaggio, scoraggiandone spesso l'uso ai meno intraprendenti (come è stato nel mio caso). La padronanza di queste tecniche distingue sicuramente un programmatore JavaScript esperto.

NOTA: la trattazione di questi argomenti presuppone una conoscenza, almeno basilare, di programmazione JavaScript.

Partiamo quindi parlando di "hoisting". Il suo significato letterale è "sollevato", il che non ci da una chiara indicazione di cosa effettivamente si tratta.

Lasciamo per un attimo da parte il significato di hoisting e concentriamoci sul codice, in quanto ci sono alcune piccole premesse da fare.

Immagino che voi tutti sappiate la differenza tra dichiarazione ed inizializzazione di variabile. Tuttavia per qualcuno può non sembrare ovvia. Assumendo myValue come variabile possiamo scrivere

Dichiarazione:

var myValue;

Inizializzazione:

var myValue = 1;

Nel secondo caso la variabile è inizializzata con un valore. Potete verificare semplicemente con un istruzione

alert(typeof myValue);

Un altro aspetto a cui occorre prestare attenzione è lo scope. Per chi proviene dai linguaggi della famiglia del C (C,C++,Java,Pascal...) non avrà problemi ad interpretare il seguente programma:

#include <stdio.h>
int main() {
  int x = 1;
  printf("%d, ", x); // output: 1
  if(1) {
    int x = 2;
    printf("%d ", x); // output: 2
  }
  printf("%d\n", x); // output: 1
}

L'output del programma sarà 1, 2, 1. I linguaggi della famiglia del C possiedono visibilità a livello di blocco (block-level scope). Pertanto quando il programma entra nel costrutto if, una nuova variabile x può essere dichiarata senza sovrascrivere la visibilità al di fuori del blocco. Con JavaScript invece il funzionamento è diverso. Proviamo a tradurre il codice precedente in JavaScript:

var x = 1;
alert(x); // output: 1
if(true) {
  var x = 2;
  alert(x); // output: 2
}
alert(x); // output: 2

Sorprendentemente l'output sarà 1, 2, 2. Perché? Semplicemente JavaScript, a differenza dei linguaggi C-like, ha visibilità a livello di funzione. I blocchi come if o while non creano un nuovo scope.

Consideriamo ora il seguente codice:

var myValue = 1;
alert(myValue); // output: 1

Come è prevedibile l'alert mostrerà 1 come output. Proviamo leggermente a modificare questo codice introducendo una funzione immediata (eseguita esattamente dove è dichiarata):

var myValue = 1;
(function() {
  alert(myValue); // output: 1
}());

L'output sarà nuovamente 1. Ovvio direte voi. Bene introduciamo un ulteriore complessità:

var myValue = 1;
(function() {
  alert(myValue); // output: ?
  var myValue = 2;
}());

Qual'è l'output in questo caso? Provatelo in firebug o in jsFiddle, vedrete che il valore dell'alert è undefined. Perché? Intuitivamente il valore dovrebbe essere 1, in quanto la nuova inizializzazione di myValue è al di sotto dell'istruzione alert.

E' qui che entra in gioco l'hoisting. Le dichiarazioni di variabili e funzioni sono sempre spostate ("sollevate"), in maniera invisibile dall'interprete JavaScript, in cima allo scope che le contiene. Pertanto il codice precedente è perfettamente analogo al seguente:

var myValue = 1;
(function() {
  var myValue;
  alert(myValue); // output: undefined
  myValue = 2;
}());

Cominciate a capire meglio come funziona, non è vero?

Fino ad ora abbiamo esaminato l'hoisting applicato alle variabili. Passiamo ora ad esaminare il caso delle funzioni:

function prova() {
  foo(); 
  function foo() {
    alert("funziona!");
  }
}
prova();

Come si comporta questo programma? Anche in questo caso l'hoisting si applica nuovamente. L'interprete JavaScript sposta la dichiarazione della funzione in cima. L'output ovviamente è "funziona", come è lecito aspettarsi. Tuttavia sappiamo che esiste un altro modo di dichiarare le funzioni, assegnandole a variabili (espressione function):

function prova() {
  foo(); 
  var foo = function() {
    alert("non funziona!");
  }
}
prova();

In questo caso riceveremo un errore (Uncaught TypeError: undefined is not a function) dovuto al fatto che solamente il nome della funzione (foo) viene sollevato, mentre il corpo della stessa viene assegnato solamente durante l'esecuzione. Quindi il codice precedente risulta perfettamente analogo a questo:

function prova() {
  var foo;
  foo(); 
  foo = function() {
    alert("non funziona!");
  }
}
prova();

L'analisi può chiudersi qui, nonostante ci siano casi particolari in cui il discorso si fa decisamente più complesso. La lezione più importante che possiamo trarre è di dichiarare le nostre variabili con un unica istruzione var limitata allo scope, sistemandola esattamente in cima, in modo da evitare la confusione derivante dall'hoisting:

function test() {
  var x,y,z;
  // codice
  x = 1;
  // più codice
  y = 2;
  // altro codice
  z = 3;
  // ulteriore codice
  return;
}

Per chi ha famililarità con l'inglese e volesse mettersi alla prova con l'hoisting, consiglio il quiz disponibile all'indirizzo http://www.nczonline.net/blog/2010/01/26/answering-baranovskiys-javascript-quiz/

Alla prossima!

Project Done

The project is almost finished. There are some little details to fix, especially in the user interface, but the most of the work is done. I'll do obviously some testing in order to check the correct behavior of the application. Then I will package the final deliver, with the source code, the ear archive, the SQL scripts and the final relation.

Little Logout Issue

In a previous post I mentioned that the connection didn't switch back to HTTP after visiting confidential pages. However I expected that after the entire logout process the website would have switch the connection back to normal HTTP, after invalidating the session. Unfortunately, I was wrong. HTTPS was still present! What to do? Google is the answer! However I was not so lucky to find a solution, maybe the question was wrong, not the answer. So I managed to build a solution on myself, which is this one: in the Logout servlet I check if the request was made using HTTP using the method request.isSecure(). If so I invalidate the session and I redirect the user to an absolute url, which is built using this string:

"http://" + getServletContext().getInitParameter("domain") + request.getContextPath() + "/index.jsp"


Where the parameter "domain" is specified in the deployment descriptor as "mauricius-pc:8080".

Few notes on SSL Security - Part II

Good practice would be to use Transport Layer Security also when user credentials are sent through the network. I searched for an easy way to implement it, directly using the j_security_check form, however, reading the following quote from the Java EE 6 tutorial I discovered that things are a little bit different:

"Form-based authentication is not particularly secure. In form-based authentication, the content of the user dialog box is sent as plain text, and the target server is not authenticated. This form of authentication can expose your user names and passwords unless all connections are overSSL. If someone can intercept the transmission, the user name and password information can easily be decoded.However, when a secure transport mechanism, such as SSL, or security at the network level, such as the IPSEC protocol or VPN strategies, is used in conjunction with form-based authentication, some of these concerns can be alleviated."


For this reason I decided to keep the authentication mechanism as it is.

Few notes on SSL Security

I decided to add support for a secure connection when sensible data is transmitted through the network. Secure data transport is typically implemented using Transport Layer Security (TLS) or Secure Sockets Layer (SSL). HTTP is applied on top of the TLS/SSL protocol to provide both encrypted communication and secure identification of the server. The combination of HTTP with TLS or SSL results in an HTTPS connection, which can be identified in a browser's address bar (https://).

I discovered that Glassfish has a secure service enabled by default (working on port 8181). This service uses a self-signed certificate, which is quite enough for our development purposes. This will lead to some annoying messages in the browser, forcing us to confirm some security exceptions, but that's it. I decided to use HTTPS in the checkout process (because an e-commerce site like this, sometimes requires the user to insert his Credit Card number or other sensitive data, however this is not the case) and in the Registration process, when the user inserts his personal data (as well as his CC number).

The secure connection is defined using XML in the web deployment descriptor, as follows:

<security-constraint>
   <display-name>Checkout</display-name>
   <web-resource-collection>
      <web-resource-name>Checkout</web-resource-name>
      <url-pattern>/checkout</url-pattern>
      <http-method>GET</http-method>
   </web-resource-collection>
   <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>
</security-constraint>


Wow, it works perfectly. Also it seems that the navigation doesn't switch back to HTTP once the user moves out from a protected page. Should I treat this as a problem? Maybe not.

I noticed on the website of the course that the exam is set for July, 6th, in the morning. Unfortunately, even if the project is almost finished (apart from some little details), I cannot be present on that date because I'm still working. I will join the September session.

JSTL or Scriptlets?

Looking back at my code I disovered that I used both JSTL tags and scriptlet code, often mixing the two in a single page. I'm aware that this is not a good practice, however writing some sections of the code I was more comfortable using JSTL tags, while in other sections I just preferred writing scriptlet code. However the overall readability of the code is not so much affected. Maybe before the final deliver I will translate everything in JSTL (which seems the best solution), but as a friend told me: "Who cares? It works!

Securing the Application

Back from holiday!!! Looking forward to finish the project. Time for a security section.

I decided to implement the basic form authentication, which appears to be the best solution in order to achieve authentication using the login form. Moreover it allows me to decide the appearance of the login form, in order to better suit the application which it belongs to.

The diagram that explains the authentication mechanism is visible in the next figure:

Form-based authentication diagram

The main point here is the keyword j_security_check which represents the destination in the servlet container that handles authorization and authentication. The action attribute of the HTML tag form must have this value.

More information about the form-based authentication is visible at the Java EE 6 tutorial: http://download.oracle.com/javaee/6/tutorial/doc/gkbaa.html#bncbq

Moreover I have to choose if I want to implement the security following a declarative paradigm or a programmatic paradigm.

• With declarative security, all the security settings of the application (authentication requirements, roles, security controls...) are specified using annotations and/or deployment descriptors.Thus the security relies on the container for its management.
• With programmatic security, the security is managed directly by entities, classes, servlets and page views. In other words, it is integrated inside the application.

Intuitively I will follow the first approach.

Building the Shopping Cart

I finally arrived at a crossroad! The requirements for this project also include the use of Stateful Session Beans. Googoling around I discovered that Stateful Beans are often used for maintaining Shopping Carts, due to their ability to track the whole user session. I also found some tutorials on how implement them. Intuitively the implementation of a shopping cart can be made by using simply the HttpSession, however Stateful Beans have considerable advantages, as this link points out: http://www.java-tips.org/java-ee-tips/enterprise-java-beans/choosing-between-httpsession-and-stateful-session.html

So I created a Stateful bean called ShoppingCart implementing the Remote interface ShoppingCartInterface. However I was not sure on how reference it in the servlets. I tried using the annotation @EJB to inject the bean, but it didn't work. Finally, digging out some stackoverflow questions, I found what I was looking for: http://stackoverflow.com/questions/2811312/stateful-ejbs-in-web-application and http://stackoverflow.com/questions/2833457/how-do-i-obtain-a-new-stateful-session-bean-in-a-servlet-thread

I had to create an object ShoppingCart and save it in the HttpSession, in order to be used across requests. I decided to create an instance of ShoppingCart when the customer goes in the Management section of the application. So using these few lines of code:


ShoppingCart cart = (ShoppingCart) session.getAttribute("cart");


if (cart == null) {
   try {
      Context ctx = new InitialContext();
      cart = (ShoppingCart) ctx.lookup("java:comp/env/cart");
      session.setAttribute("cart", cart);
   }
}


everything was magically working. 

Session Timeout

The application design is proceeding very well. I managed to finish it in a couple of weeks. Now I'm focusing on some little details, like the session timeout. This parameter can be configured in the web.xml deployment descriptor, as follows:

<session-config>
   <session-timeout>30</session-timeout>
</session-config>


The value is expressed in minutes. It's clear that a low value (say 2-5 minutes) could affect the usability of the site and have a negative impact on the customer. On the other hand, a high value means a large number of sessions managed by the application server, that could possibly lead to high memory usage. Thus perfect value, in my opinion, is 10 minutes.


However here it comes another question: how can I handle situations in which a request is received for a session that has timed out or cannot be identified? The answer is simple: using a filter that intercepts all requests and checks if a session exists, and if not, it forwards the request to the index page. What is a filter? Here the answer: http://javaboutique.internet.com/tutorials/Servlet_Filters/

Back on work again!

Finally I'm back to work. I decided to dedicate myself to the user interface of the application, because I think this is not-so-challenging task. I'm still pretty busy with other exams, so I need something easy to fill my spare time. For this purpose I bought a little manual on CSS (http://www.apogeonline.com/libri/9788850327713/scheda) which hopefully will help me through the designing process. I'm aware that CSS is often bad interpreted on different browsers, especially in IE (wow!!! Really?), but I am not going to care so much about that fact: the design is working on my Firefox 3.6? Perfect! I'm done!

Temporary Suspension

Unfortunately I have to dedicate myself on other projects and exams, thus I planned to stop working on this project. I hope to restart soon. See ya!

JPA and Many-to-Many relationships

I spent a few days in order to clearly comprehend how JPA really works. In particular I was hesitant about the relation between the User table and the Instructor/Customer tables. After generating the Entity classes from the tables using the guided procedure on Eclipse I discovered that the User entity had a many-to-many relation with Customer and a many-to-many relation with Instructor. I was not sure if it was correct and how I had to manage it, however it turned out that everything was correct and the matter was simpler than I could ever expected.

The relation was clearly many-to-many due to the connection tables user_customer and user_instructor. For this reason the User entity has a Set of Customer entity and a Set of Instructor entity in it. So accessing one of the two, after retrieving the User from the DB using the email as PK, was quite a joke:

User user = em.find(User.class, email);
Customer customer = user.getCustomers().iterator().next();

Et voilà! I have my Customer entity ready for use.

Here are some useful links on the subject:
http://www.giuseppesicari.it/articoli/jpa-java-persistence-api/
http://en.wikibooks.org/wiki/Java_Persistence/Relationships
http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html

domain.xml damaged

Unfortunately today I went straight into an unexpected blackout. I didn't lost anything because I used to save my work very often, however when I switched back on my PC I discovered that Glassfish was not working anymore. By double-clicking on the Glassfish server in the Servers tab of Eclipse I discovered that the Server Port Number and Admin Server Port Number parameters were setted to the wrong values (8080111 and 4848111 respectively instead of 8080 and 4848). Trying to launch Glassfish I always received an error message, which was obviously that 8080111 was not a valid port in the range 1 - 65536. After an hour of investigation I discovered that the domain.xml file inside the glassfish/domains/domain1/config folder was completely corrupted. Luckily in the same folder there was a backup file called domain.xml.bak, so I just copy-paste the content inside the original file and everything worked again.

JDBC Realm in Glassfish

Following the Java EE 6 Tutorial I discovered how to secure the Application Server.
In particular I need an authentication mechanism for identify the users and give access to specific resources. In my project there are 3 kinds of users: customers, instructors and the agency (or the admin/superuser in this case). This means that we have 3 different roles with different privileges. The declaration of a role is defined in the web.xml file, in the following way:

<security-role>
   <description>User role</description>
   <role-name>USER</role-name>
</security-role>

The mapping between users and roles is specified in the sun-web.xml file, as following:

<security-role-mapping>
   <role-name>USER</role-name>
   <group-name>customer</group-name>
</security-role-mapping>

For my requirements the better solution is to configure a realm, which is a complete database of users and groups that identify valid users of a web application and are controlled by the same authentication
policy. Configuring a JDBC Realm on Glassfish is pretty simple. I followed this link, which is a bit old, but is suitable for our purposes. In the administration console of Glassfish we have to go on Configurations, Security and Realms, then we can add a new Realm.

These are the values of my SnowInstructionsRealm:

Realm Name: SnowInstructionsRealm
Class Name: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm

JAAS Context: jdbcRealm
JNDI: jdbc/snowinstructions
User Table: user
User Name Column: email
Password Column: password
Group Table: user
Group Name Column: groupid
Digest Algorithm: none

It's important to note that the credentials of users and the corresponding role are saved inside the same table (user). Also each user can be mapped only to one group (which are agency, instructor, customer), which is the better choice in this case. Moreover the password are stored in clear inside the database (Digest Algorithm is set to none) in order to simplify the project in the initial phases. Maybe before the final deliver I will add the MD5 support. If you don't insert any value this option will be the default one.

Glassfish + MySQL JDBC Connection Pool

I used MySQL Workbench 5.2 (http://wb.mysql.com/) in order to create the Database. Next step was to use the Glassfish Administration console to configure a JDBC Connection Pool and JDBC Resources. I followed the tutorial visible at this page http://www.albeesonline.com/blog/2008/08/06/creating-and-configuring-a-mysql-datasource-in-glassfish-application-server/.

These are my values:

JDBC Connection Pool
Pool Name: SIPool
Resource Type: javax.sql.DataSource
Database Vendor: MySQL

Additional Properties
portNumber: 3306
databaseName: sidatabase
serverName: localhost
user: root
password: root
URL: jdbc:mysql://localhost:3306/sidatabase
url: jdbc:mysql://localhost:3306/sidatabase

By clicking on the Ping button I received the Ping Succeeded Message meaning that my connection was correctly configured.

Then I created a JDBC Resource using the JNDI Name jdbc/snowinstructions referring to the Connection Pool created before (SIPool).

Note that we need to have the mysql-connector-java-bin.jar (http://www.mysql.com/downloads/connector/j/) library inside the glassfish/lib folder in order to get everything right.

Database Structure

This is the structrure of the Database. It's possible to see the tables and the relations between them.

IDE and Application Server choice

For the project I decided to use the Eclipse IDE with Glassfish 3.1 and MySQL as RDBMS. The main reason for this choice is because I used them on the Service Oriented Architecture course and so they were already configured on my machine. I always had problems with Java EE application servers on my laptop (which is 64 bit) due to various bugs and other crap, so I decided to keep this configuration which is pretty stable at the moment. Let's hope it lasts!

Business Flow

In order to point out the relations between the mockup pages and also to understand the functionality of each page, I prepared a business diagram which demonstrates the process flow of the application. It displays the visual and functional components on each page and highlights the primary actions available for the user in order to complete the purchase process.

I also created the application logo using Photoshop. It's the nice and simple writing on the index page!